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The  primary  objective  of  this  research  effort  was  to 
trace  the  evolution  of  a  decision  support  system  for  a 
fighter  training  unit  scheduler.  The  purpose  of  a  Decision 
Support  System  (DSS)  is  to  assist  the  cognitive  processes  of 
judgment  and  choice  as  performed  by  a  squadron  scheduler. 

Fighter  squadron  dally  scheduling  is  a  complex  and  time 
consuming  task.  Currently,  squadron  scheduling  is  accom¬ 
plished  using  plexiglas  grease  boards  and  manual  tracking 
systems.  It  is  a  manpower  intensive  task  requiring  vast 
amounts  of  cross-referencing  and  a  great  deal  of  attention 
to  detail. 

This  DSS  is  built  using  the  adaptive  design  process. 

The  adaptive  design  process  includes  development  of  a  con¬ 
cept  map,  analysis  of  tasks  and  data,  and  identification  of 
the  kernel  to  select  the  central  decision  process.  The  de¬ 
signers  employ  this  central  decision  process  to  develop  a 
feature  chart  and  storyboards,  the  starting  point  for  the 
DSS  construction. 

Ideally,  the  DSS  begins  with  a  small  prototype  that 
decision  makers  use  and  evaluate.  Builders  then  customize 
and  modify  the  DSS  as  a  result  of  user  feedback.  This  pro¬ 
cess  repeats,  incorporating  user  needs  and  requirements. 
Thus,  the  DSS  improves  with  each  successive  iteration. 

This  particular  DSS  automates  the  squadron  scheduling 
decision  process  without  interrupting  the  schedulers  ability 
to  concentrate  on  the. task  at  hand.  This  DSS  interfaces 
with  an  automated  wing  procedure.  The  procedure  currently 
used  at  Holloman  AFB  supplies  each  fighter  squadron  with 
daily  flying  information  on  a  computer  disk.  This  DSS  pro¬ 
cesses  the  data  residing  on  the  disk  and  automatically  dis¬ 
plays  the  scheduling  framework,  eliminating  the  need  for 
grease  boards.  The  DSS  database  tracks  the  availability  of 
personnel,  thus  replacing  two  more  scheduling  grease  boards. 
Elimination  of  the  grease  boards  frees  the  scheduler  from 
the  time-consuming  process  of  manually  updating  them. 

Elimination  of  the  grease  boards  saves  time,  thus  im¬ 
proving  scheduling  efficiency.  Currently,  near  the  end  of 
the  day  the  scheduler  may  not  have  time  to  correct  last 
minute  changes  to  an  already  complex  schedule.  Lack  of  time 
may  result  in  disastrous  consequences.  Mistakes  usually  oc¬ 
cur  at  this  point,  in  which  case  crews  may  not  fly  missions. 
This  DSS  minimizes  the  time  necessary  to  update  a  compli¬ 
cated  schedule  accurately,  thus  giving  the  scheduler  more 
time  to  assign  individuals.  As  a  result  of  this  DSS,  more 
quality  flying  training  will  be  accomplished. 
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DESIGN  EVOLUTION 
OF  A 

FIGHTER  TRAINING  SCHEDULING 
DECISION  SUPPORT  SYSTEM 


The  squadron  scheduling  job  at  the  434**  and  4351 


training  squadrons  at  Holloman  AFB ,  New  Mexico  is  a  time 
consuming,  hard,  complicated,  and  thankless  job.  The  sched¬ 


ulers  favorite  saying  is,  ‘a  perfect  job  merits  no  increase 
in  punishment.*  With  two  classes  of  about  25  -  30  students 


each,  the  schedulers  work  with  a  confusing  maze  of  syllabus 


t  i”  r';  t. 


and  squadron  rules.  The  435**  works  with  seven  different 
syllabi;  the  434**  requires  only  four  different  syllabi. 
Near  the  end  of  the  day,  when  time  is  a  factor,  small 
changes  result  in  catastrophes  for  the  next  day’s  schedule 
The  following  five  elements  are  part  of  the  scheduling 


problem: 


1.  Manual  Scheduling. 

2.  Deconf liction. 

3.  Lack  of  Alternatives . 

4.  Unaccomplished  Prerequisites. 

5.  Mismatched  Student/Instructor. 


Manual  Schedul ing .  Tho  first  of  these  elements  deals 
with  the  intensive  manual  tracking  of  all  duties  on  several 
grease  boards.  The  scheduler  writes  the  duties  manually 


V 
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onto  the  boards.  Table  1.1  lists  the  grease  boards  a  sched¬ 
uler  works  with  on  a  daily  basis. 

TABLE  1 . 1 

Duty  Scheduler's  Qrease  Boards 


1 . 

Today's  Duty  Schedule 

2. 

Tomorrow's  Duty  Schedule 

3. 

Monthly  Instructor  Duties 

4. 

Student  Training  Board 

5. 

Deconf liction  Board 

6. 

Squadron  Schedule  Board 

Iflday,' a  Duty  Schedule.  The  schedulers  keep  the 
current  day’s  flying  schedule  to  note  any  deviations  that 
happen  during  the  day.  Due  to  late  takeoffs,  changed  range 

times,  or  lack  of  fuel,  the  current  day's  schedule  may 

l 

change.  Tomorrow's  duty  schedule  takes  into  account  any 
discrepancies  from  the  current  day’s  schedule 

Tomorrow's  Hu&X  Schedule .  The  duty  scheduler 
writes  on  a  portable  plexiglas  board  what  each  student  and 
I  instructor  is  doing  the  next  day.  Figure  1.1  depicts  a  typ- 

|  ical  daily  duty  schedule  found  on  a  squadron  grease 

I  board  (range  and  area  times  have  been  left  out  for  clarity). 
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Month 1 Y  Instructor  Put Isa .  Tha  achadular  writ** 
tha  Instructor  pilot  monthly  dutias  on  anothar  graa sa  board. 
Instructor  Pilots  (IPs)  art  thosa  axpariancad  pilots  that 
hava  at  laast  400  hours  in  fightar-typa  aircraft.  An  axan* 
pla  of  his  waakly  duty  might  ba  Suparvisor  of  Plying  (SOP) , 
Bangs  Control  Officar  (RCO) ,  or  Duty  Schadular  (saa  Appandix 
K) .  Each  duty  raquiras  from  half  to  a  who la  day’s  affort  to 
accomplish . 

Studs  lit  Training  Board.  Anothar  plaxiglas  board 
that  raquiras  intansiva  manual  tracking  is  tha  studant 
training  board.  Studants  going  through  Laad-In  Pightar 
Training  (LIPT)  must  complata  80  avants  during  thair  43 
training  days.  Tha  studant  training  board  tracks  tha  com- 
plation  or  failura  of  studant  training  avants.  With  30  stu¬ 
dants  in  training,  tha  schadular  manually  tracks  about  50 
avants  aach  day  on  tha  board.  Pigura  1.2,  dapicting  this 
board,  shows  tha  studants  and  tha  avants  thay  must  accom¬ 
plish.  Upon  avant  complation,  tha  schadular  antars  a  data 
in  tha  appropriata  squara . 

Daconf llctlon  Board .  Tha  schadular  antars  tha 
avant  and  tima  onto  tha  daconf lict ion  board  whan  ha  schad- 
ulas  any  parsonnal.  Tha  schadular  rafarancas  tha  daconf lic- 
tion  board  to  saa  if  ha  schadulad  mora  than  ona  avant  at  tha 


saaia  tima.  This  board  ansuras  that  tha  squadron  schadula 
doas  not  contain  any  conflicts. 
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Fig.  1.2  Student  Training  Board 


Squadron  Scheduling  Board.  The  squadron  schedul¬ 
ing  board  is  a  large  plexiglas  board  displaying  both  today’s 
and  tomorrow’s  schedules.  This  board  shows  the  complete 
schedule  for  all  squadron  personnel.  It  incorporates  all 
the  meetings  and  appointments  for  everyone. 

The  day  prior,  the  scheduler  must  know  anything  that 
will  keep  one  of  the  assigned  squadron  personnel  from  par¬ 
ticipating  in  the  next  day’s  activities.  The  scheduler  man¬ 
ually  tracks  special  notes  on  small  cards.  If  a  student  or 
IP  cannot  fly  for  medical  reasons  (e.g.,  a  cold  or  flu)  he 
is  put  into  Duty  Not  Involving  Flying  (DNIF)  status.  The 
scheduler  does  not  consider  DNIF  personnel  for  the  next 
day’s  flying  schedule.  For  example,  an  IP  with  a  future 
dental  appointment  writes  the  date  on  a  small  card  and  gives 
it  to  the  scheduler. . 

Manual  tracking  of  all  the  above  procedures  can  result 
in  inaccuracies.  A  typical  day’s  manual  tracking  procedure 
follows.  Upon  completion  of  the  day’s  flying,  the  duty 
scheduler  writes  the  events  on  the  student  training  board. 

An  event  is  an  occurrence  of  an  aircraft  ride  or  other 
required  procedure  for  an  individual.  Instructor  pilots 
that  accomplish  SOF  or  RCO  are  also  annotated.  Throughout 
the  day,  the  duty  scheduler  works  the  next  day’s  schedule  as 
if  all  of  the  current  day’s  events  were  accomplished.  Once 
the  next  day's  schedule  is  complete,  administrative  person¬ 
nel  copy  it  to  the  squadron  scheduling  board  for  all  of  the 


squadron  personnel  to  check.  Since  the  scheduler  manually 
updates  each  board  daily,  there  is  a  chance  for  error. 

Deconf 1 iction .  The  duty  scheduler  maintains  a  decon- 
fliction  board  to  prevent  scheduling  two  events  at  the  same 
time  for  a  single  individual.  During  the  day  the  duty 
scheduler  continually  updates  the  deconf liction  board.  In 
theory,  the  board  should  provide  deconf 1 iction  for  everyone. 
Yet,  near  the  end  of  the  day,  when  the  scheduler  makes  last- 
minute  changes  to  an  already  complex  and  interwoven  sched¬ 
ule,  he  can  easily  make  mistakes.  Many  IP’s  are  already 
scheduled  for  two  daily  events  and  any  change  to  their 
schedule  often  goes  unnoticed  until  it  is  too  late. 

Lack  of  A1 ternatl vea .  Many  times  the  duty  scheduler 
has  woven  a  tight  knit  schedule  that  comes  unraveled  at  the 
last  minute  due  to  a  ’ripple  effect’  through  his  schedule. 
Last  minute  changes  to  the  schedule  require  the  duty  sched¬ 
uler  to  look  for  alternative  IPs  or  students  to  fill  slots. 
By  1300-1500  hours  each  day  the  duty  scheduler  has  matched 
instructors  and  students  with  takeoff  times.  The  schedule 


for  the  next  day  must  change  if  a  failed  ride  occurs  or  an 
unknown  meeting  arises  after  1500.  The  scheduler  consults 
several  boards  to  make  a  change  to  this  intricate  schedule. 


The  scheduler  must  rapidly  evaluate: 


1.  Which  students  are  available  and  at  what  time? 

2.  Which  instructors? 

3.  If  the  duty  scheduler  changes  the  event  time  of 
one  person,  does  it  affect  an  earlier  event? 

4.  Changes  may  violate  crew  rest  rules  and  thus 
affect  flight  safety. 


(Inaccomplished  Prerequisites .  A  student  must  accom¬ 
plish  about  80  different  events  in  the  proper  order  during 
his  stay  at  Holloman.  For  example,  to  fly  his  first  ride  a 
student  must  accomplish  six  hours  of  life  support  training, 
one  hour  of  squadron  briefing,  and  one  hour  of  simulator 
training.  If  the  scheduler  puts  a  student  in  his  first 
flight  without  having  accomplished  these  specific  events,  he 
is  unprepared  to  fly  and  may  endanger  his  life.  Therefore, 
to  ensure  that  the  students  do  their  prerequisites  before 
the  flight,  the  scheduling  shop  tracks  the  events  on  another 
large  plexiglas  board  (Figure  1.3).  This  tracking  requires 
daily  intensive  manual  effort  so  no  one  flies  without  com¬ 
pleting  their  prerequisites. 

Ml  amAt.fjhed  Student/ Instructor  .  Schedulers  must  prop¬ 
erly  match  students  and  instructors  before  flying  together. 
Squadron  supervisors  screen  the  students  upon  arriving  at 
Holloman  to  determine  if  they  have  any  special  instructional 
needs.  An  example  would  be  if  a  student  had  spent  one-and- 
a-half  years  at  AFIT,  then  four  years  at  the  Pentagon  in 
Studies  and  Analysis.  Because  of  his  extended  absence  from 
flying,  the  student  would  assume  'red  dot'  status  and  could 
fly  only  with  red  dot  instructors. 
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The  operations  officer  selects  experienced  instructors  to  be 
red  dot  instructors.  They  usually  have  had  at  least  one  year 
of  flying  with  students.  If  the  scheduler  allows  a  red  dot 
student  to  fly  with  a  non-red  dot  instructor  pilot,  he  com¬ 
promises  flight  safety  and  a  dangerous  situation  results. 

The  problem  presented  in  this  chapter  provided  a 
reference  point  for  the  research.  To  explore  avenues  and 
approaches  to  the  problem,  it  was  necessary  to  perform  a 
literature  search.  This  search  reviewed  some  past  ap¬ 
proaches,  efforts,  or  solutions  to  the  scheduling  problem. 

Literature  Review 

The  discussion  presents  previous  research  efforts  in 
the  area  of  scheduling  in  four  parts.  The  first  part  deals 
with  a  general  review  of  the  various  types  of  scheduling 
problems  and  solution  techniques.  The  next  portion  deals 
with  the  network  approach  to  solving  scheduling  problems. 

The  third  part  overviews  the  use  of  simulation  as  a  schedul¬ 
ing  tool.  The  final  part  looks  at  the  decision  support  sys¬ 
tem  (DSS)  approach. 

Schedul inf  Research .  A  general  review  of  the  various 
types  of  scheduling  problems  and  solution  techniques  yielded 
the  following  problems:  Job  shop  scheduling,  maintenance 
scheduling,  and  cyclical  scheduling. 

il ah  Shop  Schedul  ing  .  Job  shop  problems  scheduled 
items  moving  through  a  shop.  The  purpose  was  to  schedule 
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each  job  in  a  specific  order  at  the  proper  time  or  in  a  ran¬ 
dom  order  (depending  on  the  job  shop) .  Each  item  may  have 
required  a  visit  to  each  machine  a  certain  number  of  times, 
or  it  may  only  have  visited  some  subset  of  the  machines  in 
the  shop.  Moreover,  there  may  have  been  several  types  of 
jobs  which  required  different  subsets  of  machines  or  differ¬ 
ent  types  of  flow  patterns.  Solutions  to  job  shop  problems 
usually  used  integer  linear  programming  (ILP)  or  heuristic 
techniques.  Often,  these  solutions  were  developed  for  spe¬ 
cific  problems  rather  than  providing  a  general  solution  for 
all  job  shop  problems.  The  literature  in  this  area  dealt 
with  finding  algorithms  or  exploring  how  to  solve  the  same 
problem  using  different  solutions. 

Hosios  used  a  heuristic  algorithm  that  scheduled  a  min¬ 
imum  number  of  personnel  for  completion  of  a  set  of  activi¬ 
ties  every  scheduling  period  (6:749).  The  activities 
occurred  at  various  times  and  locations.  The  algorithm 
assumed  that  the  personnel  can  complete  the  activities  in 
any  order . 

Student  scheduling  at  Holloman  requires  the  completion 
of  a  set  of  activities  every  scheduling  period.  However, 
the  order  of  completion  is  important  and  adds  to  the  student 
scheduling  problem.  Although  Hosios  does  not  consider  com¬ 
pletion  order  in  his  article,  all  personnel  complete  all 
activities.  This  is  similar  to  the  student  scheduling 
problem. 


Problems  in  this  area 


dealt  with  repair  crew  assignment,  optimal  maintenance 
facility  flow,  or  manpower  requirements  (13:333-340; 
23:2770-2775).  The  objective  of  maintenance  scheduling  was 
to  minimize  cost  by  either  reducing  manpower  requirements  or 
reducing  repair  costs.  This  minimization  required  an  opti¬ 
mal  allocation  of  repair  crews  and  money  to  the  equipment 
being  maintained. 

(  Both  maintenance  and  student  scheduling  required  the 

!  assignment  of  scarce  resources.  Both  types  of  scheduling 

< 

i 

I  must  consider  a  structured  schedule  of  events  (e.g.,  tech- 

orders  for  maintenance  and  syllabi  for  student  scheduling). 
In  addition,  both  techniques  dealt  with  manning  require¬ 
ments.  The  drawback  of  maintenance  scheduling  was  that  it 
was  not  flexible  enough  to  deal  with  the  constant  changes  in 
the  training  arena. 

Cyclical  Scheduling ■  This  involved  the  scheduling 
of  people  for  shift  work  or  a  schedule  of  on-  and  off-days, 
such  as  nurse  scheduling.  Warner  developed  a  nursing  sched¬ 
ule  that  considered  weekdays  off,  work  stretches  (consec¬ 
utive  work  days),  single  days  off,  and  undesirable  work  pat¬ 
terns  (back-to-back  shifts).  Integer  linear  programming  and 
heuristics  were  the  main  techniques  used  to  solve  these 
types  of  problems. 

However,  cyclical  scheduling  fell  short  of  providing 
all  the  answers  for  the  student  scheduling  problem  in  two 
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area*.  First,  user*  must  schedule  more  than  one  type  of 
activity  for  students.  The  Holloman  schedule  includes 
classroom  lecture,  simulator  training,  and  flying  sorties. 
Second,  cyclical  scheduling  literature  does  not  consider 
leave,  DNIF,  TDY,  and  other  disruptions.  Therefore,  cycli¬ 
cal  scheduling  will  not  be  used  (3:1-10). 

Goal  Pt»q gnemmi  n g  .  Arthur  and  Ravindran  proposed  a 
goal  programming  approach  to  the  nurse  scheduling  problem 
(2:55-60).  Goal  programming  incorporated  several  goals  into 
the  objective  function,  seeking  to  simultaneously  optimize 
all  the  goals.  This  optimization  technique  provided  an 
added  degree  of  flexibility  to  the  scheduling  program  in 
that  it  would  substitute  different  goals  into  the  program  if 
desired. 

Warner’s  use  of  a  set  of  weighted  criteria  was  very 
similar  to  goal  programming.  Multi-criteria  decision  theory 
(MCDT)  used  a  set  of  weighted  measures  of  of f ectiveness 
(22:842-850) . 

network  Approach.  Roege  used  integer  programming, 
based  on  branch  and  bound  techniques,  to  solve  pilot 
scheduling  in  a  fighter  squadron  (10:50).  Roege  used  TAC 
Manual  51-50  training  requirement  minimum*  as  lower  bound 
constraints.  The  model  developed  considers  crew  rest 
restrictions  and  absences  from  duty.  His  model  ensured  that 
each  pilot  received  at  least  a  minimum  and  no  more  than  a 
maximum  number  of  flights  per  week. 


The  main  drawback  of  Roege  ia  that  he  considered  only 


experienced  pilots  (there  is  no  student  training  or  instruc¬ 
tor/student  matching).  In  addition,  he  did  not  consider  any 
extra  duties  such  as  SOF,  ECO,  or  Duty  Officer  (see  Appendix 
K) .  Roege  did  start  his  formulation  with  a  ‘shell.*  A 
shell  is  a  listing  of  takeoff  times,  number  and  type  of  sor¬ 
ties,  and  configuration  of  the  aircraft.  The  shell  is  a 
very  important  starting  point  for  the  student  scheduling 
problem  at  Holloman  AFB. 

Simulation  Approach .  Berg  used  simulation  to  assist 
the  scheduling  of  missile  crews  (3) .  Berg  took  several  user 
input  factors  and  automated  them  to  produce  a  schedule. 
Missile  crews  flowed  through  a  network  that  completed  events 
at  specified  times.  MCDT  techniques  and  Response  Surface 
Methodology  provided  a  worth  assessment  of  each  schedule. 

Berg’s  idea  of  assisting  the  scheduler  is  important  in 
the  student  scheduling  problem  at  Holloman.  However,  he 
still  proceeded  with  the  ‘push-button  approach'  to  schedul¬ 
ing.  That  is,  the  machine  or  algorithm  scheduled  for  the 
user  at  the  push  of  a  button.  This  concept  made  it  inappro¬ 
priate  for  the  student  scheduling  problem  at  Holloman. 
Schedulers  must  know  the  reasoning  behind  the  decision  pro¬ 
cess.  In  addition,  scheduler  interaction  is  essential  to 
have  a  flexible  and  robust  scheduling  system. 

Hoi  1 amen ’ a  Efforts .  Capt  Votipka  used  LOTUS  1-2-3 
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on  a  Z-100  computer  in  an  attempt  to  schedule  students  and 
instructors.  He  scheduled  students  and  instructors  on  a 
time  line  type  screen  display.  Capt  Votipka  attempted  this 
at  Holloman  AFB ,  New  Mexico  at  the  479**  Tactical  Training 
Wing.  His  attempt  found  limited  success  for  the  following 
reasons : 

1.  The  computer  screen  could  not  show  all  flights  on 
one  screen. 

2.  The  refresh  rate  of  the  screen  was  too  slow  for 
the  users. 

3.  The  computers  were  unfamiliar  and  hard  to  use  for 
the  untrained  user. 

Dft.fi la ion  Support  Systems 

The  above  techniques  did  not  specifically  concern  them¬ 
selves  with  the  decision  maker  and  the  information  required 
to  make  effective  decisions.  Oonin  and  Moffett  ‘argue  that 
complex  decision  making  requires  human  interaction  with 
graphical  displays  that  are  in  the  spirit  of  the  Decision 
Support  approach  (10:9).‘  According  to  Maj .  Valusek,  a  DSS 
is  a  system,  manual  or  automated,  that  assists  the  cognitive 
processes  of  judgment  and  choice  (20) . 

A  DSS  would  allow  the  scheduler  to  recall  needed  infor¬ 
mation  from  the  database,  consider  the  data  presented,  make 
a  decision,  and  input  the  decision  into  the  schedule.  He 
updates  the  schedule  to  determine  the  effect  of  the  deci¬ 
sion.  In  this  way  users  build  schedules  that  reflect  the 
decision  maker’s  desires  in  an  efficient  manner. 


Attempts  to  solve  the  student  scheduling  problem  with 
the  push  of  a  button  would  be  distrusted.  Even  if  a  com¬ 
puter  algorithm  solved  the  problem  instantly,  the  unit 
commander  would  be  wary  of  a  solution  with  no  human  in  the 
decision  loop.  Humans  solve  the  problem  quite  well  every 
day  by  heuristic  decision  processes.  A  DSS  assists  in  the 
decision  process  rather  than  making  decisions. 

Why  Adaptive  Design 

Adaptive  design  is  an  approach  to  problem  solving  for 
semi -structured  and  unstructured  problems  (structure  is  the 
amount  of  definition  a  problem  has).  A  small  ‘kernel  sys¬ 
tem*  grows  or  changes  as  requirements  are  added  or  modified. 
A  kernel  system  is  that  part  of  a  complete  decision  process 
considered  to  be  the  essential  core  of  that  process. 

This  small  kernel  provides  the  starting  point  about 
which  the  system  will  grow.  The  system  will  expand  around 
user  needs  and  requirements.  As  user  needs  change,  the  sys¬ 
tem  adapts  to  these  new  requirements.  This  adaptive  ability 
is  an  advantage  over  the  complete  system  approach.  Steps  in 
the  adaptive  design  process  are: 

1.  Select  the  Bight  Problem 

2.  Identify  key  kernel 

3.  Iterative  Design 

4.  Implementation 

The  complete  system  approach  ‘freezes*  user  require¬ 
ments  before  the  start  of  construction.  Because  a  ‘complete 


system*  takes  so  long  to  develop,  user  needs  change.  If 
these  needs  have  changed,  the  system,  when  fielded,  no 
longer  reflects  current  user  requirements.  In  addition,  the 
user’s  perceptions  or  environment  may  change.  The  chance 
that  these  views  match  the  'complete  system’  characteristics 
is  remote.  Therefore,  the  complete  system  method  is  inade¬ 
quate  for  a  dynamic,  flexible  problem  such  as  scheduling. 

Student  scheduling  at  Holloman  is  still  a  time  consum¬ 
ing,  complex  task.  Schedulers  routinely  make  mistakes  which 
may  affect  flight  safety.  This  is  normally  the  result  of 
either  scheduling  someone  for  two  different  events  at  the 
same  time  or  violating  one  of  the  many  rules  that  exist.  An 
example  might  be,  in  the  former  case,  scheduling  students 
simul taneously  for  class  and  a  simulator  training  ride. 
Another  example  is  scheduling  a  student  to  fly  the  night 
before  an  early  morning  flight,  as  in  the  latter  case.  Not 
only  does  this  affect  flying  safety,  it  is  a  large  price  for 
the  duty  scheduler,  his  commander,  and  the  squadron  to  pay 
for  many  hours  of  careful  scheduling  should  an  accident 
occur . 

The  problems  of  manual  tracking,  deconf liction ,  unac¬ 
complished  prerequisites ,  mismatched  instructor/student 
crews,  and  insufficient  alternatives  make  it  a  hard,  but 
possible,  task  to  computerize.  However,  allowing  the 
squadron  itself  to  create  a  scheduling  program  that  it  can 
use  and  evolve  is  a  new  approach.  With  the  introduction  of 


powerful  Zenith  model  248  (Z-248)  microcomputer*  available 
at  the  unit  level  (8),  each  squadron  will  be  able  to  adapt  a 
kernel  scheduling  system  to  meet  its  own  needs.  Of  course, 
this  project  needs  technical  expertise.  The  wing  must  be 
able  to  provide  support  to  change  and  adapt  the  program  as 
new  requirements  or  problems  arise.  Squadron  and  wing 
scheduling  at  Holloman  should  work  closely  to  further  the 
computerization  of  their  scheduling  system. 

Research  Ecchlaa 

Schedulers  currently  have  no  means  to  adequately  and 
quickly  manipulate  a  vast  database  to  produce  an  accurate 
and  timely  student  flying  training  schedule.  Although 
scheduling  rules  and  restrictions  are  quite  clear,  time  con- 
straints  introduce  problems.  The  scheduler  must  precisely 
and  quickly  interpret  a  large  amount  of  information. 

Research  Qhlectlve 

The  research  objective  was  to  trace  and  document  the 
evolutionary  design  process  of  a  DSS  that  assists  in 
scheduling  daily  student  flying  training.  The  effort  used 
appropriate  software  on  a  Z-248  microprocessor  in  the  434** 
Flying  Training  Squadron  at  Holloman  AFB.  In  addition,  this 
effort  showed  how  end  users  can  use  off-the-shelf  software 


on  Z-248’s  to  build  their  own  decision  aids. 


1.  Document  the  adaptive  design  process  of  the  DSS . 

2.  Use  a  kernel  identification  process  to  identify 
and  test  the  core  of  the  decision  process . 

3.  Create  a  picture  of  what  the  program  should  look 
like  before  development  (‘Storyboard*). 

4.  Maintain  a  future  goals  section  that  are  not 
currently,  attainable  ( ‘  Hookbook  ' )  . 


Scope  .  Limitations  .  juxd  Assumptions 

This  thesis  focused  at  the  unit  level  duty  scheduler  at 
Holloman  AFB  in  the  434**  and  435**  Squadrons.  The  authors 
designed  the  program  specifically  for  the  Z-248  microproces¬ 
sor.  The  scheduling  system  did  not  make  any  decisions  for 
the  scheduler,  but  assisted  him  and  supported  decisions  he 
made.  Emphasis  of  this  research  focused  on  the  evolutionary 
design  approach  to  build  the  DSS  kernel. 

Chapter  II  deals  with  the  approach  selected.  Chapter 
II  also  covers  the  reasons  for  DSS  use  and  software  selec¬ 
tion.  Chapter  III  shows  how  the  techniques  described  in 
Chapter  II  apply  to  a  specific  DSS.  Chapter  IV  describes 
the  resulting  system  and  how  it  varied  from  the  planned  sys¬ 
tem.  Chapter  V  addresses  conclusions  and  recommendations  of 
the  scheduling  system  and  the  adaptive  design  process  in 


general . 


II .  Problem  Approach 


Initial  Conception 

The  initial  idea  was  to  build  a  scheduling  tool  to  as¬ 
sist  the  squadron  scheduling  for  the  training  squadrons  at 
Holloman  AFB ,  New  Mexico.  The  idea  seemed  appealing  for  the 
following  reasons: 

1.  Previous  Scheduling  Experience; 

2.  Microcomputers  were  in  all  of  the  squadrons; 

3.  The  problem  seemed  like  it  should  be  solvable; 

4.  Operations  Research  'optimizes*,  so  Operations 
Research  should  be  able  to  help  in  the  scheduling 
area ; 

5.  All  TAC  squadrons  schedule  essentially  the  same 
way  (man-hour  intensive  process) ; 

6.  The  topic  was  unclassified;  and 

7.  There  is  nothing  currently  in  the  field  to  help 
at  the  squadron  level . 

Approach  Selection 

After  investigating  approaches,  there  were  two  strong 
candidates,  expert  systems  (ES)  and  DSS  (14; 20).  Turban  and 
Watkins  compared  ES  .and  CSSs  in  their  article.  Table  2.1 
highlights  the  differences  between  ES  and  DSS. 
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TABLE  2 . 1 


The  Differences  Between  ES  and  DSS 


DSS 

ES 

Ob J ective 

Assist  human 

Replicate  (mimic)  human 
and  replace  him/her 

Who  makes 

the  decision? 

The  human 

The  system 

Maj  or 

orientation 

Decision  making 

Transfer  of  expertise 
(human- machine -human) 

Query 

direction 

Human  queries 

Machine  queries  the 

the  machine 

human 

Clients 

Individual  and/or 
group  user 

Individual  user 

Manipulation 

Numerical 

Symbolics 

Problem  Area 

Complex, 

integrated,  wide 

Narrow  domain 

Database 

Factual  knowledge 

Procedural  and  factual 
knowledge 

(19: 141) 


The  authors  selected  DSS  because  it  offered  an  approach 
to  complex,  integrated  problems.  Machines  assist .  but  do 
not  replace,  the  decision  maker.  ES ,  on  the  other  hand, 
suggested  rather  than  supported  decisions.  *ES  typically 
involves  a  closed-world  assumption,  that  is,  the  problem 
domain  is  circumscribed,  and  the  system  performance  is  con¬ 
fined  within  those  boundaries’  (9).  In  DSS  contexts,  the 
world  was  open.  A  DSS  must  be  flexible  and  adaptive  to  meet 
the  changing  conditions  in  the  environment  and  the  evolving 


needs  of  the  user  (18). 


A  TDY  to  Holloman  AFB ,  New  Mexico  (23-26  Aug  86) 
revealed  that  the  scheduling  problem  still  existed.  Inter¬ 
views  with  several  wing  and  squadron  schedulers  revealed  the 


scheduling  problems  shown  in  Table  2.2. 

TABLE  2 . 2 

Scheduling  Problems  at  Holloman  AFB 

1.  Undocumented  DNIF,  Leave  and  TDY 

2.  Last-minute  changes  wrought  havoc 

3.  All  flights  not  shown  on  one  screen 

4.  Deconf liction  of  schedule  often  inaccurate 

5.  Mo  sorting  or  priori tization  capability 

6.  Intense  manual  tracking  was  time  consuming 
and  often  produced  errors 


The  479**  wanted  the  project  automated  to  correct  the 
above  problems.  In  fact,  the  479**  wing  scheduling  had 
already  automated  their  portion  of  the  daily  flying  sched¬ 
ule.  The  479**  wing  scheduling  sends  the  daily  sortie  in¬ 
formation,  generated  by  a  computer  program,  to  the  squadrons 
on  a  floppy  disk.  Table  2.3  shows  an  actual  copy  of  a  file 
used  on  3  March  1987  to  give  sortie  information  to  the  434** 


TFTS . 


TABLE  2.3 


479***  Wing  Scheduling  File 


Land  time  — 
Takeoff  time 
Unused 
Line  • 


(I  3 


(minutes  past 
midnight) 


-Area  time 
-Man  type 
-Conf  ig 
-Area 


461 

6 

510 

610 

1 

520 

560 

SA 

B-l 

oSc 

402 

0 

510 

610 

1 

520 

550 

SA 

B-l 

OSC 

403 

0 

510 

610 

1 

520 

550 

SA 

B-l 

OSC 

404 

0 

510 

610 

1 

520 

550 

SA 

B-l 

OSC 

405 

0 

555 

655 

1 

565 

605 

B 

E-l 

BK-C 

406 

0 

555 

655 

1 

565 

605 

B 

E-l 

BK-C 

407 

0 

570 

670 

1 

580 

610 

SA 

B-l 

OSC 

408 

0 

370 

670 

1 

580 

610 

SA 

B-l 

OSC 

409 

0 

570 

670 

1 

580 

610 

SA 

B-l 

OSC 

410 

0 

570 

670 

1 

580 

610 

SA 

B-l 

OSC 

411 

0 

690 

790 

1 

700 

730 

SA 

B-l 

OSC 

412 

0 

690 

790 

1 

700 

730 

SA 

B-l 

OSC 

413 

0 

690 

790 

1 

700 

730 

SA 

B-l 

OSC 

414 

0 

690 

790 

1 

700 

730 

SA 

B-l 

OSC 

415 

0 

735 

835 

1 

745 

785 

B 

E-l 

BK-B 

416 

0 

735 

835 

1  • 

745 

785 

B 

E-l 

BK-B 

417 

0 

750 

850 

1 

760 

790 

SA 

B-l 

OSC 

418 

0 

750 

850 

1 

760 

790 

SA 

B-l 

OSC 

419 

0 

750 

850 

* 

760 

790 

SA 

B-l 

OSC 

420 

0 

750 

850 

1 

760 

790 

SA 

B-l 

OSC 

421 

0 

870 

970 

1 

880 

920 

F 

E-l 

BK-B/BK-C 

422 

0 

870 

970 

1 

880 

920 

F 

E-l 

BK-B/BK-C 

423 

0 

870 

970 

1 

880 

920 

F 

E-l 

BK-B/BK-C 

424 

0 

870 

970 

1 

880 

920 

F 

E-l 

BK-B/BK-C 

425 

0 

915 

1015 

1 

925 

965 

B 

E-l 

BK-C 

426 

0 

915 

1015 

1 

925 

965 

B 

E-l 

BK-C 

427 

0 

930 

1030 

1 

940 

980 

F 

E-l 

TL-E/TL-W 

428 

0 

930 

1030 

1 

940 

980 

F 

E-l 

TL-E/TL-W 

429 

0 

930 

1030 

1 

940 

980 

F 

E-l 

TL-E/TL-W 

430 

0 

930 

1030 

1 

940 

980 

F 

E-l 

TL-E/TL-W 

The  479***  wing  computer  manager,  Capt  Votipka,  men¬ 
tioned  that  the  wing  had  ordered  six  Z-248’s,  two  for  wing 
and  one  for  each  squadron.  Capt  Votipka  also  mentioned 
ENABLE,  an  integrated  software  package,  came  with  the  Z- 


The  method  used  to  solve  this  particular  problem  stems 
from  an  evolutionary  design  process  and  its  application  to  a 
DSS  capable  of  assisting  unit  schedulers  at  Holloman  AFB . 

The  entire  scheduling  process  must  satisfy  user  needs  when 
builders  construct  the  DSS.  The  authors  used  four  essential 
steps  to  construct  this  system  and  achieve  the  objectives. 

The  first  step  involved  documenting  the  daily  decision 
process  schedulers  use  to  generate  a  workable  schedule. 

This  task  involved  building  a  conceptual  map,  or  network,  of 
the  scheduling  process  followed  by  a  task  and  data  analysis. 
These  analyses  trace  the  flow  of  information  used  in  build¬ 
ing  the  daily  flying  lists.  Once  builders  understand  this 
network,  it  is  necessary  to  organize  it  in  as  simple  a  way 
as  possible. 

The  next  step  involves  storyboarding,  or  designing  ini¬ 
tial  computer  screen  representations  of  the  decision  process 
(1).  The  scheduler  should  have  all  of  the  information 
needed  to  construct  the  daily  flight  agenda.  On  the  other 
hand,  this  screen  format  must  present  enough  of  the  ‘big 
picture*  of  the  next  day's  tasks  to  minimize  errors  and 
oversights . 

The  third  step  is  to  encode  a  kernel  program,  using 
acceptable  software,  which  will  implement  the  storyboard 
output  and  provide  as  much  assistance  to  the  scheduler  as 
needed.  The  software  must  support  the  storyboarded  format. 


In  addition,  it  must  be  powerful  enough  to  suj  port  changes 
or  modifications  as  user  requirements  evolve. 


L> 


Jl 


Finally,  once  the  builders  construct  the  kernel, 
assessment  by  the  users  at  Holloman  is  necessary  to  obtain 
feedback  needed  for  DSS  evolution.  This  will  entail  actual 
"hands-on*  operation  of  the  program  to  stimulate  user  com¬ 
ments  and  critiques  of  the  ability  of  the  DSS  to  aid  sched¬ 
uling.  Taking  the  feedback  into  account,  further  modifica¬ 
tion  or  adaptation  of  the  scheduling  DSS  may  take  place.  In 
this  way,  builders  may  track  successive  generations  of  the 
system  to  trace  the  design  evolution  of  a  DSS. 


Problem 


Problem  definition  is  perhaps  the  most  difficult  part 
of  building  a  DSS.  The  unstructured  nature  of  a  DSS  problem 
complicates  matters  because  the  true  problem  may  lie  beneath 
layers  of  information  or  heuristic  processes.  Keeping  this 
in  mind,  the  two  steps  to  follow  in  defining  the  problem  are 
recognition  and  identification. 

The  first  step,  problem  recognition,  is  the  easiest  of 
the  two  steps.  When  procedures  or  tasks  within  an  organiza¬ 
tion  do  not  run  smoothly,  it  is  easy  to  recognize  that  some 
problem  exists.  If  this  difficulty  surfaced  recently,  com¬ 
parison  with  past  events  or  procedures  provides  the  refer¬ 
ence  with  which  to  compare  the  problem’s  nature  and  extent. 
On  the  other  hand,  if  the  organization  is  looking  to  improve 


(i.e.,  trying  to  discover  any  problems)  or  streamline  their 
operation,  the  problem  may  not  immediately  expose  itself. 

At  this  point,  knowledge  of  the  specific  organizational  pro¬ 
cedures  is  necessary  to  understand  the  scope  of  the  problem. 
It  may  be  helpful  to  interview  the  novice  employee  first,  as 
he  does  not  have  the  expertise  required  to  overcome  or  cir¬ 
cumvent  daily  operational  hurdles.  Problems,  in  his  eyes, 
are  magnified  and  easily  recognized.  The  interviewer  mu3t 
exercise  caution,  however,  because  the  novice  often  has  lit¬ 
tle  experience  with  his  environment  (the  way  his  work  inter¬ 
acts  with  the  organization).  As  such,  his  perception  may 
exaggerate  the  problem  or  prove  inconsequential  to  the  deci¬ 
sion  process.  Col laboration.  wi th  the  experts,  then,  should 
reveal  whether  the  problem  is  valid.  Chapter  III  covers 
problem  recognition  for  the  specific  scheduling  DSS .  Once 
the  interviewer  is  certain  a  problem  or  area  of  improvement 
exists,  the  next  step  is  to  find  out  just  what  that  problem 
is . 

Problem  identification  normally  requires  the  aid  of  the 
problem  system  experts  due  to  the  complex  nature  of  an  orga¬ 
nization's  specific  decision  requirements.  These  experts 
are  necessary  to  interpret  the  problem  fully  and  understand 
it’s  impact  on  both  the  decision  and  the  environment. 

Through  successive  interviews  and  queries  with  these 
experts,  the  DSS  builder  gains  insight  about  the  problem 
facing  the  decision  maker. 


For  this  specific  DSS ,  the  builders  are  the  scheduling 


experts.  Each  author  is  experienced  in  fighter  training 
squadron  scheduling.  Therefore,  the  authors  drew  upon  their 
experience  for  problem  identification.  The  next  step  in 
problem  identification  is  the  concept  map. 

Concept  Majl  Development 

Conceptual  mapping  outlines  each  portion  of  the 
decision  process  using  words  or  concepts  and  linking  words 
or  phrases  in  a  hierarchical  depiction  (12:3).  Conceptual 
mapping  captures  the  components  of  the  decision-maker’s  pro¬ 
cess  and  provides  a  rough  definition.  Figure  2.1  graphi¬ 
cally  depicts  the  general  method  of  developing  a  conceptual 
map.  Chapter  III  describes  the  DSS  developed  for 
scheduling . 

First-cut  of  the  Decision  Process .  This  process  starts 
by  independently  interviewing  each  user  to  establish  a  com¬ 
mon  reference  to  the  decision  process.  The  interview 
focuses  upon  the  general  decision  process ,  trying  to  iden¬ 
tify  clearly  the  methods  each  expert  employs.  This  first- 
cut  of  the  problem  concentrates  upon  general  topics  for  both 
simplicity  and  understanding.  The  users  complete  what  they 
think  to  be  the  decision  process  using  only  word  phrases  and 
linking  words.  Once  the  interviewer  annotates  all  of  the 
decisions,  the  next  step  is  to  note  the  important  ones. 
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Figure  2.1.  The  Method  of  Developing  a  Conceptual  Map 


Liat  Main  Deciaiona .  The  users  separate  the  main  deci¬ 
sions  from  the  first-cut  list  of  all  the  decisions.  The 
lists  from  each  user  are  essentially  the  same  as  the  first- 
cut  lists  but  divided  into  main  topics  (decisions) .  Once 
the  interviewer  categorizes  the  decisions,  the  next  step  is 
to  order  the  decisions. 

Order  Decisions .  From  these  lists,  the  experts  rank 
the  concepts  in  a  time-ordered  manner  (i.e.,  assign  a  number 
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to  those  concepts  which  must  be  performed  in  a  certain 
order).  The  interviewer  combines  all  the  expert’s  decisions 
at  this  point. 

Rough  Concept  Map .  From  all  of  the  ordered  lists,  the 
interviewer  consolidates  the  expert’s  individual  lists  into 
one  network  (Chapter  III  explains  the  actual  networks) . 

From  these  initial  concept  maps,  a  rough  idea  of  the  deci¬ 
sion  process  structure  emerges.  An  analysis  of  all  the  maps 
together  provides  a  basic  idea  of  the  true  decision  process. 

Sacand-cut  al  Decision  Process .  Prior  to  this  point, 
the  interviews  were  independent  to  reduce  possible  bias. 

Now  the  users  meet  as  a  group  to  critique  the  rough  concept 
map.  From  this  network,  the  users  dissect  each  concept  to 
arrive  at  an  understandable  decision  process.  More  inter¬ 
views  with  personnel  of  varying  experience  levels  provide 
different  results. 

Concept  Map  Formulation .  From  the  analysis  done  previ¬ 
ously,  the  concept  map  reduces  to  major  ideas.  From  this 
simplified  concept  map,  the  interviewer  may  identify  the 
kernel (s) .  Later  sections  expand  upon  this  concept. 

Task  Analysis 

The  task  analysis  represents  the  detailed  steps  needed 
to  accomplish  the  decision.  Patterned  after  the  concept 
map,  this  analysis  takes  the  form  of  a  network  and  includes 
each  task  the  scheduler  (in  this  case)  must  perform  and  the 


order  he  performs  them  in.  This  network,  once  completed, 
allows  identification  of  the  kernel  as  well  as  pinpoints 
possible  bottlenecks  within  the  system.  Through  experience, 
testing,  and  monitoring,  the  interviewer  uses  these  choke- 
points  to  find  the  shortest  path  through  the  system.  Once 
the  process  finds  the  path,  the  builders  may  create  proce¬ 
dures  to  assist  the  DM. 

Analysis 

A  further  test  of  the  task  analysis  validity  is  the 
data  analysis.  This  procedure  traces  actual  data  throughout 
the  task  analysis  to  ensure  compliance  with  the  decision 
process.  This  procedure  also  helps  map  the  data  flow  to 
ease  construction  of  databases  used  in  the  DSS.  Appendix  D 
contains  the  database  relations  discovered  by  the  tracing 
procedure . 

Fftftlurs  Chart  Definition 

With  the  task  and  data  analyses  completed,  the  next 
step  in  the  system  development  was  to  construct  the  feature 
chart  (17).  This  chart  is  a  representation  which  encom¬ 
passes  the  tasks  and  the  features  necessary  to  accomplish 
that  task.  The  DSS  should  be  able  to  assist  users  with  var¬ 


ied  experience  and  individual  techniques,  yet  not  be  cumber¬ 
some  to  interpret  or  manipulate.  At  the  same  time  the  DSS 


must  be  powerful  enough  to  support  any  decision  sequences 
the  user  may  require.  The  latter  requisite  may  be  accom¬ 
plished  using  an  iterative  approach  over  a  period  of  time 
with  the  user  employing  the  DSS  and  relying  on  the  structure 
of  the  kernel  to  assist  him.  As  such,  this  feature  chart 
concerns  the  development  of  the  screen  output  format  based 
on  the  decision  process  and  task/data  analyses  identified  in 
the  previous  section. 

The  builders  employ  the  Representation ,  Operations, 
Memory  aids,  and  Control  mechanisms  (ROMC)  user-builder 
interface  technique  (18:101-100)  to  develop  the  feature 
chart.  Each  of  these  tools  enables  the  designer  to  trans¬ 
late  user  requirements  into  DSS  components.  This  permits 
the  translation  of  the  user’s  needs  to  the  builder’s  design 
requirements.  Consideration  of  these  aspects  help  build  a 
single  effective  output  screen  in  the  storyboard. 

Representation,  the  first  tool,  depicts  the  actual 
screen  presentation  needed  by  the  user.  This  data  represen¬ 
tation  must  satisfy  the  user’s  needs  in  a  clear  and  concise 
manner.  The  order  of  the  representations  must  be  logical, 
conforming  to  the  user's  decision  or  thought  process 
sequence.  This  is  especially  important  because  the  DSS 
should  not  distract  the  user  as  he  thinks,  rather  it  should 
ease  his  decisions  by  presenting  him  the  next  piece  of 
information  when  needed.  Should  the  user  require  closer 
look  at  a  particular  piece  of  data  or  focus  on  a  portion  of 


the  screen  ,  manipulation  of  the  representation  may  be 
necessary . 

The  second  tool,  operations,  enable  the  user  to  manipu¬ 
late  the  representations  on  the  screen  to  suit  his  individ¬ 
ual  technique.  This  may  take  the  form  of  actual  data  manip¬ 
ulation  (e.g.,  sorting),  scale  change  (e.g.,  viewing  a 
larger  or  smaller  portion  of  the  screen)  ,  or  adding/deleting 
various  amounts  of  data  for  clarity  or  interpretation.  The 
user  must  easily  accomplish  these  operations  at  his  conve¬ 
nience  without  interrupting  his  thought  process. 

The  next  tool  used  in  constructing  the  feature  chart  is 
memory  aids.  These  helpful  reminders  guide  the  user  through 
his  decision  process  with  the  use  of  icons,  windows,  high¬ 
lighted  (colored)  information,  or  various  flags.  All  these 
methods  serve  to  trigger  or  jog  the  user’s  memory,  reminding 
or  warning  him  of  certain  decisions. 

Finally,  control  mechanisms  are  interwoven  throughout 
the  entire  system,  allowing  any  user  to  skip  tedious  or 
familiar  processes.  These  mechanisms  support  the  user’s 
decision  process,  allowing  ease  of  movement  to  any  part  of 
the  system.  Control  mechanisms  may  take  the  form  of 
selectable  menus  or  predefined  function  keys. 

Chapter  III  shows  how  the  techniques  described  in  this 
chapter  were  used  to  develop  a  scheduling  DSS. 


I 
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The  specific  system  development  takes  the  problem 
described  in  Chapter  I  and  uses  the  framework  outlined  in 
Chapter  II  to  determine  the  key  kernel.  Figure  3.1  depicts 
the  steps  necessary  to  implement  the  key  kernel .  To  ensure 

i  _ 


(12:5) 


Figure  3.1.  Decision  Support  System  Development  Steps 


the  DSS  provides  the  correct  information,  the  builders  use 
the  steps  described  above.  The  process  starts  with  the 
concept  map  development. 

Concept  Map 

Conceptual  mapping,  as  applied  to  this  specific  DSS, 
deals  with  the  scheduler’s  decision  procedure.  It  is  the 
relationship  (18:225-226)  between  the  scheduler  and  the 
schedule  he  produces  -  a  road  map  from  blank  paper  to  com¬ 
pleted  schedule.  It  outlines  the  scheduling  decision  pro¬ 
cess  using  words  or  concepts  and  linking  words  or  phrases  in 
a  hierarchical  depiction  (12:3). 

To  construct  the  concept  map,  the  builder  must  first 
understand  the  nature  of  the  decision  process.  System 
experts  provide  the  best  source  of  information  about  an 
organization’s  specific  processes.  Since  the  builders  for 
this  specific  scheduling  DSS  were  also  the  experts,  they 
already  knew  what  was  important.  Thus,  this  characteristic 
is  important  to  end-user  application.  Figure  3.2  depicts 
the  initial  decision  process  the  authors  envisioned.  Capt 
Michael  McFarren ,  conducting  graduate  research  in  the  field 
of  concept  mapping  and  cognitive  development,  guided  the 
authors  through  the  mapping  and  analysis  portions  of  the 
system  development  via  a  series  of  interviews. 
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Figure  3.2.  Scheduler's  Decision  Process 


Firat-cut  flX  the  Decialon  Process .  This  process 
started  by  independently  interviewing  each  author  to  estab¬ 
lish  a  common  reference  to  scheduling.  Both  authors  com¬ 
pleted  what  they  thought  to  be  the  daily  scheduling  process 
using  word  phrases  and  linking  words  (Table  3.1). 


TABLE.  3 . 1 


First  Cut  Conceptual  Map  Word  Phrases 


1.  Check  yesterday’s  schedule  for  deviations. 

2.  Gather  tomorrow’s  BNIF  inputs. 

3.  Gather  tomorrow’s  academic  inputs. 

4.  Gather  tomorrow's  TDY  inputs. 

5.  Gather  tomorrow’s  leave  inputs. 

6.  Gather  tomorrow’s  simulator  inputs. 

7.  Gather  tomorrow’s  appointment  inputs. 

8.  Gather  tomorrow’s  hard  line  inputs. 

9.  Gather  tomorrow’s  duty  inputs. 

10.  Fill  Shell  flights  with  students. 

11.  Fill  Shell  flights  with  matched  instructors. 

12.  Fill  Shell  academic  classes  with  students. 

13.  Fill  Shell  additional  duties. 

14.  Fill  Shell  appointments. 

15.  Fill  Shell  meetings. 

16.  Deconflict  throughout. 


Appendix  B  contains  the  actual  lists.  Once  the  scheduling 
decisions  were  annotated,  the  next  step  was  to  annotate  the 
important  ones. 

List  Main  Decisions .  The  authors,  under  Capt 
McFarren ’ s  supervision,  separated  the  main  decisions  from 
the  first-cut  list  of  all  the  scheduling  decisions.  The 
lists  from  each  author  were  essentially  the  same  as  the 
first-cut  lists  (see  Appendix  B) ,  but  divided  into  main 
topic  areas.  Table  3.2  summarizes  the  main  tasks  and  deci¬ 
sion  areas  found  in  both  author’s  lists. 
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TABLE  3.2 


Main  Tasks/Decisions  from  First-cut  Word  Phrases 


Check  yesterday’s 
Gather  tomorrow's 


schedule  for  deviations, 
inputs  -  determine  priority. 


a . 

DNIF 

e . 

Simulator 

b. 

Academic 

f  . 

Appointments 

c . 

TDY 

Hard  Lines 

d. 

Leave 

h. 

Additional  Duties 

Fill 

Fill 

Fill 

Fill 

Fill 

Fill 


Shell 

Shell 

Shell 

Shell 

Shell 

Shell 


Deconflict 


flights  with  students. 

flights  with  matched  instructors 

academic  classes  with  students. 

additional  duties. 

appointments . 

meetings. 

throughout . 


Order  Decisions .  From  the  above  lists,  Capt  McFarren 
instructed  the  authors  to  rank  the  concepts  in  a  time 


TABLE  3.3 


Ordered  List  of  Main  Decisions 


Check  yesterday’s  schedule  for  deviations. 
Gather  tomorrow's  inputs  -  determine  priority 


a. 

DHIF 

e . 

Simulator 

b. 

Academic 

f  . 

Appointments 

c . 

TDY 

«• 

Hard  Lines 

d. 

Leave 

h. 

Additional  Duties 

Fill 

Fill 

Fill 

Fill 

Fill 

Fill 


Shell 

Shell 

Shell 

Shell 

Shell 

Shell 


Deconf 1 ict 


academic  classes  with  students. 

additional  duties. 

flights  with  students. 

flights  with  matched  instructors. 

appointments . 

meetings . 

throughout . 
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ordered  manner  by  assigning  a  number  to  those  concepts  which 
must  be  performed  in  a  certain  order  (Table  3.3).  Appendix 
B  contains  the  actual  lists.  Note  Table  3.3  varies  only  in 
order  form  Table  3.2.  Capt  McFarren  combined  both  concept 
structures  at  this  point,  thus  taking  the  next  step  in 
system  development. 

Rough  Concept  Map .  From  the  ordered  lists,  Capt 
McFarren  had  the  authors  draw  and  order  their  individual 
lists  into  networks.  Appendix  B  contains  the  actual  net¬ 
works.  From  these  initial  concept  maps,  a  rough  idea  of  the 
decision  process  structure  emerges.  Figure  3.3  shows  a  very 
complex  and  interwoven  process  a  scheduler  must  wade  through 
to  complete  a  daily  schedule. 

Second-cut  of  Decision  Process .  Up  to  this  point,  the 
interviews  were  conducted  independently  to  reduce  possible 
bias.  Also,  there  was  no  contact  between  the  authors  con¬ 
cerning  the  concept  mapping.  From  this  n.etwork,  Capt 
McFarren  and  both  authors  dissected  each  concept  to  arrive 
at  an  understandable  decision  process.  It  may  be  noted  here 
that  only  two  subjects  were  used  in  the  analysis.  Appendix 
B  contains  the  iterations  of  the  decision  process. 

The  major  finding  was  that  the  whole  process  was  very 
database  intensive.  This  database  took  the  form  of  manual 
grease  board  tracking  schemes  for  personnel  events.  In 
fact,  there  was  a  question  whether  there  was  any  need  for  a 
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Figure  3.3.  Bough  Concept  Map 


DSS  because  there  seemed  to  be  no  decisions  involved.  Fur¬ 
ther  study  verified  that  proper  manipulation  and  presenta¬ 
tion  of  the  database  was  crucial  to  the  matching  of  the 
instructors  with  the  students.  A  DSS  does  need  to  include  a 
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good  user/machine  interlace.  Furthermore,  a  DSS  should 


include  good  dialogue  with  the  user. 

Concept  Map  Formulation .  The  concept  map  was  now 
reduced  to  only  the  major  ideas.  Figure  3.4  depicts  the 
actual  decision  but  not  all  the  data-related  inputs  neces¬ 
sary  to  achieve  that  decision.  From  this  simplified  concept 
map,  the  users  and/or  builders  may  identify  the  kernels 
(later  sections  expand  on  this).  With  the  help  of  Capt 
McFarren ,  the  authors  traced  the  steps  necessary  to  make  a 
decision . 


Figure  3.4.  Formulated  Concept  Map 


Task  Analysis 


For  this  specific  DSS ,  Capt  McFarren  analyzed  the 
inputs  obtained  from  interviewing  the  authors.  Figure  3.5 
depicts  the  task  analysis  derived  in  Appendix  C.  When  given 
the  student  grouping/sorting  criteria  (students  must  accom- 


Figure  3.5.  Task  Analysis 


plish  certain  events)  and  instructor  availability  for  those 
certain  events,  the  scheduler  must  assign  students  to  the 
Shell  and  match  them  with  the  appropriate  instructors.  Only 
when  provided  with  current  information  may  the  schedulers 
accurately  accomplish  the  next  day’s  schedule.  Note  that 
the  grease  board  database  provides  student  grouping/sorting 
and  instructor  availability.  Also,  since  certain  student 
events  are  predetermined,  their  assignment  to  the  shell 
requires  little  decision  on  the  scheduler's  part.  As  such, 
the  primary  decision  emphasis  becomes  matching  the 
instructors.  The  following  sections  discuss  this  resulting 
kernel  identification. 

Because  the  schedule  seldom  happens  as  predicted,  the 
whole  decision  process  may  be  interrupted  at  any  time.  Capt 
McFarren  noted  this  process  of  interference  in  Figure  3.8. 
The  greatest  effect  this  serves  is  to  adjust  the  databases, 
depending  on  the  problem,  forcing  the  scheduler  to  rematch 
his  student/ instructor  resources.  From  a  scheduling  stand¬ 
point,  the  process  in  Figure  3.6  is  normally  where  most 
assignment  errors  occur  due  to  limited  time  available  to 
update  the  deconf 1 ict ion/avai labi 1 i ty  grease  boards.  This 
is  because  interruptions  happen  near  the  time  the  schedule 
is  due.  Because  every  scheduler  has  his  own  technique  when 
filling  in  the  possible  events  and  handling  interruptions, 
the  builders  sought  a  general  procedure  to  map  the  decision 
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Figure  3.6.  Task  Analysis  Interruptions 

process.  The  experience  of  the  authors  verified  the  accu¬ 
racy  of  the  decision  process  as  represented  by  the  task 
analysis . 

Data  Analysis 

This  procedure  traces  actual  data  throughout  the  task 
analysis  to  ensure  compliance  with  the  decision  process.  It 
also  helps  map  the  data  flow  to  ease  construction  for  DSS 
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databases.  Appendix  D  contains  the  database  relations  found 
in  the  tracing  procedure. 

Ee.aA.ur, a  Chart  Development 

Table  3.4  shows  the  information  the  scheduler  needs. 


TABLE  3.4 

Scheduler  Information 


A. 

Tomorrow's  schedule. 

1.  Available  students. 

2.  Available  instructors. 

3.  Priority  considerations. 

4.  Ability  to  print  schedule. 

B. 

Today’s  schedule. 

1.  Ability  to  update  events. 

C. 

Schedule  inputs. 

1.  Flying  sortie  lines  from  wing 

2.  Simulator  lines  from  wing. 

3.  Student. 

a.  Availability. 

b.  Assigned  instructors. 

4.  Instructor  Status. 

5.  Academic  classes  and  instructors. 

6.  Duties  and  meetings. 

D. 

Statistics . 

1.  Time  line  by  class. 

2.  Time  line  by  individual  student. 

E. 

Course  changes. 

1.  Student  syllabus. 

2.  Class  additions/deletions . 

This  information  is  represented  by  a  network  hierarchy 
(Figure  3.7).  Once  the  builders  establish  this  network, 
they  may  design  the  storyboard  using  the  feature  chart  ROMC 
tools  mentioned  previously. 


Figure  3.7.  Feature  Chart  Hierarchy 


Using  the  scheduling  screen  hierarchy  depicted  in 
Figure  3.7,  the  storyboard  focuses  purely  upon  the  require¬ 
ments  needed  by  the  user.  There  was  no  bias  toward  any  com¬ 
mercial  software  or  particular  capabilities  or  limitations. 
This  process  reflected  the  user’s  needs  without  regard  to 
any  technological  restraint.  Should  a  limitation  occur 
after  the  builders  develop  the  feature  chart,  they  will  mod¬ 
ify  the  DSS  to  include  as  much  as  possible  within  current 
commercial  software  bounds. 

The  evolution  of  the  system  via  the  feature  chart  con¬ 
centrates  on  the  overall  system  and  the  individual  portions. 
Each  category  is  important  because  the  builders  construct 
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the  DSS  from  these  features.  Each  individual  storyboard  and 
its  evolution  (Appendix  F)  started  from  the  original  story¬ 
board.  The  initial  programming  focused  on  implementation  of 
the  storyboard. 

Storyboard 

A  problem  facing  the  storyboard  itself  is  how  to  place 
all  of  the  necessary  information  on  the  screen  without  clut¬ 
tering  the  presentation.  The  easiest  way  is  to  diagram 
carefully  all  of  the  system  components.  The  builders  then 
arrange  and  group  these  parts  in  a  logical  manner  according 
to  the  user’s  decision  process.  The  builders  then  order  and 
incorporate  these  parts  into  the  screen  design.  Appendix  E 
depicts  the  incorporation  of  the  feature  chart  into  an 
actual  screen  output  format  following  the  feature  chart 
hierarchy  (Figure  3.7).  As  previously  mentioned,  the  objec¬ 
tive  in  the  storyboard  was  to  create  the  ideal  scheduling 
screens  -  what  the  scheduler  needed  to  see  -  without 
technological  constraints. 

Kamel  Identification 

The  concept  of  a  kernel  is  a  portion  of  the  decision 
process  under  consideration .  As  such,  a  process  may  consist 
of  several  kernels.  For  example,  to  buy  a  car  there  are 
several  kernels  (concepts)  involved.  The  decisions  about 
what  the  DM  needs  or  wants,  the  type  of  car  on  the  market, 
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and  the  DM’ *  financial  status  would  all  be  poaaible  kernela. 
Selection  of  the  kernels  uses  the  concept  map  and  task/data 


analyses  to  identify  the  main  ideas/concepts  present  in  the 


decision  process . 


&X.  the  Kernel  (a)  .  The  concept  map  shown 


in  Figure  3.4  shows  the  three  central  portions  of  the 


scheduling  decision  process: 

1)  Determination  of  the  available  resources 

2)  Event  prerequisites 

3)  Instructor- to-student  matching 

The  task  analysis  in  Figure  3.5  confirms  the  three  central 
concepts  of  resource  availability,  student  event  prerequi¬ 
sites,  and  instructor-to-student  matching. 


&KX  Kernel 


Thus,  given  the  three  kernels 


from  which  to  select,  the  determination  of  the  key  kernel  is 


only  a  matter  of  deciding  which  of  the  three  is  the  moat 
important  1a  Ike  user .  The  concept  map  (Figure  3.4)  merely 
identifies  the  kernels  without  bias.  A  further  analysis  of 


the  problem  via  a  task  analysis  (Figure  3.5)  clearly  cen¬ 
tralizes  the  importance  of  the  instructor-to-student  match¬ 
ing.  The  concept  map  provided  the  greatest  indication  in 
that  the  matching  is  the  only  decision  kernel  in  the  entire 
scheduling  process.  The  other  two  kernels  are  only  database 
references  and,  while  an  important  portion  of  the  decision 
process  (as  inputs) ,  are  less  important  to  the  construction 
of  the  DSS .  Thus,  the  key  kernel  is  the  instructor- to- 
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student  matching  and  became  the  point  to  start  construction 
of  the  DSS . 


Kernel  Evaluation 

Kernel  evaluation  may  take  place  in  three  areas:  The 
relation  of  the  kernel  to  its  environment,  validation  of  the 
kernel  identification,  and  verification  of  the  key  kernel. 
The  builders  must  evaluate  the  DSS  in  each  of  these  three 
areas  to  confirm  they  used  the  correct  kernel  for  DSS  con¬ 
struction.  Otherwise,  the  builders  may  direct  their  con¬ 
struction  efforts  on  peripheral  kernels. 

Environment .  The  scheduling  environment  consists  of 
the  interaction  of  wing  inputs  to  the  squadron,  the 
squadron’s  interaction  with  its  personnel,  and  completion 
and  presentation  of  a  finished  schedule  back  to  wing.  When 
considering  which  kernel  (s)  to  choose,  the  entire  scheduling 
process  hinges  on  the  squadron  schedulers  and  the  daily 
choices  they  must  make.  Wing  is  merely  an  input  source  and 
the  recipient  of  the  final  product.  This  essentially  places 
the  decision  process  at  the  squadron  level.  Squadron  top 
echelons  rely  on  the  scheduling  shop  to  build  the  schedule. 
Like  wing,  the  echelons  input  requests  and  check  the  sched¬ 
ule  before  sending  it  to  wing.  This  narrows  the  environment 
to  the  scheduling  shop  and  the  individual  schedulers  who 
construct  the  actual  schedule  and  amend  it  should  any 
changes  (or  additional  inputs)  occur. 


Kernel  Selection .  Builders  (both  designers  and  users) 
accomplish  kernel  identification  with  an  understanding  of 
the  scheduling  decision  process.  As  mentioned  in  the  previ¬ 
ous  sections,  evaluation  success  takes  the  form  of  the  accu¬ 
racy  of  the  process.  Also,  the  concept  map  and  task  analy¬ 
sis  are  of  a  generic  form,  accommodating  the  particular 
styles  of  individual  schedulers.  Figure  3.4  identifies  the 
three  kernels  using  the  steps  in  Chapters  II  and  III: 

1.  Resources  (availability)  ....  Database 

2.  Event  prerequisites  (events)  .  .  Database 

3.  Instructor/student  matching  .  .  Decision 

Key  Kernel .  Derived  from  the  concept  map  and  task 
analysis,  selection  of  the  key  kernel  is  valid  as  well.  In 
tracing  both  the  task  and  data  analyses,  the  key  kernel  of 
instructor-to-student  matching  becomes  the  focal  decision 
point.  In  other  words,  matching  is  the  primary  decision  the 
user  makes.  Thus,  matching  is  the  central  concept  about 
which  the  scheduling  process  revolves.  Therefore,  with  all 
three  of  the  kernel  evaluation  criteria  met,  construction  of 
the  DSS  began.  Building  focused  upon  matching  the  instruc¬ 
tors  to  students  placed  upon  the  schedule.  From  there,  the 
builders  included  resource  availability  and  event  prerequi¬ 
sites  as  the  adaptive  design/evolution  process  continued. 

Continuing  Evaluation .  Evaluation  must  be  a  continuing 


process.  Feedback  must  be  gathered  on  the  DSS  performance 
to  modify  the  system.  Users  will  have  complaints  about  the 
DSS.  Appendix  J  details  how  to  evaluate  the  DSS  after  it 


has  been  implemented.  Listed  below  is  a  summary  of  these 
suggestions  (52:161-166). 


Event  Logging .  Users  would  write  in  a  notebook, 
kept  next  to  the  DSS ,  any  comments  about  DSS  performance. 

Attitude  Survey .  A  questionnaire  of  multiple- 
choice,  short  statement,  or  open-ended  questions  should  be 
used  throughout  the  DSS  implementation  and  development. 

Rating  and  Weighing .  The  methodology  involves 
developing  a  set  of  parameters  related  to  the  system  and 
effects  being  evaluated,  weighting  these  parameters  in  terms 
of  relative  importance,  and  having  one  or  more  individuals 
rate  the  system  on  each  parameter.  Examples  of  these  param¬ 
eters  include  schedule  creation  time,  number  of  scheduling 
deviations,  or  percentage  of  primary  instructor  correctly 
assigned . 

System  Measurement .  This  method  attempts  to  quan¬ 
tify  effects  through  measurements  of  the  performance  of  the 
target  system,  and  therefore  it  is  similar  to  performance 
evaluation . 

Value  Analysis .  The  approach  attempts  to  quantify 
subjective  value  judgments. 

Combining  Methods .  Because  of  the  variety  and 
complexity  of  the  potential  effects  and  because  there  are 
problems  with  all  evaluation  methods,  a  combination  of  meth¬ 
ods  will  probably  result  in  the  best  evaluation. 
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Once  the  Holloman  schedulers  provided  the  basic  frame 
work  for  the  DSS  requirements,  the  authors  identified  the 
programming  language  characteristics.  Tables  3.5  and  3.6 


show  the  desired  features  and  characteristics  of  a  DSS. 

Considering  the  above  features,  the  authors  selected 
five  integrated  software  packages  for  further  evaluation: 

1.  ABILITY  (Version  1.0) 

2.  LOTUS  SYMPHONY  (Version  1.2) 

3.  LOTUS  1-2-3  (Version  2.0) 

4.  ENABLE  (Version'  1.15) 

5.  R : BASE  SERIES  5000 

TABLE  3.5 

Desirable  Language  Features 


®  Integrated  database  management  (probably  relational) 
®  User  friendliness  to  nontechnicians 

®  Both  procedural  and  nonprocedural  command  structures 
®  Interactive  on-line  utilization 

«  Support  of  prototyping  and  adaptive  development 
«  Modest  training  requirements  for  end  users 

•  Easy  debugging  and  intelligent  default  assumptions 
®  Little  or  no  Complex  Code  (Cobol  ,  Fortran,  etc.) 

•  Internal  documentation  generation  support 

•  Understandable  code  for  non-developers 


Integrated  software  packages  are  software  that  contain 
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database,  spreadsheet,  word  processing,  graphics,  and 
(usually)  telecommuni cat ions  programs.  Integrated  means 
that  each  of  the  five  capabilities  can  work  together  to  form 
a  powerful  product.  Table  3.6  shows  further  selection 
criteria. 


TABLE  3.6 


Desirable  Language  Characteristics 


<n  Low  Cost 


«  Reliability 
«  Availability 
®  Compatibility 


«  Maintainability 


«  End  user  orientation 


w  Programmer  productivity 

«  Hardware/Software  operating  environment 


(11: 176-177) 


Table  3.7  depicts  the  software  characteristics  for  each 
of  the  five  packages  under  consideration.  The  authors 
selected  ENABLE  for  the  following  reasons:  1)  ENABLE  comes 
with  the  Z-248  microprocessor  so  the  cost  is  minimal;  2) 
ENABLE  will  be  available  to  the  training  squadrons  at 


Holloman;  3)  The  software  requires  low  maintenance  (e.g., 
program  modifications/changes)  by  users  and  is  highly 


TABLE  3.7 

Integrated  Software  Comparisons 
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ABILITY 

-  99 

X 

IBM 

HIGH 

MED 

NO 

NO 

SYMPHONY 

695 

X 

IBM 

LOW 

MED 

HIGH 

YES 

YES 

1-2-3 

549 

X 

IBM 

MED 

MED 

MED 

■9 

YES 

ENABLE 

#  78 

X 

IBM 

LOW 

HIGH 

HIGH 

YES 

YES 

R : BASE 

700 

X 

IBM 

LOW 

HIGH 

HIGH 

NO 

YES 

» 

Government  Price 

(15: 129) 


friendly  (does  not  let  the  user  make  mistakes);  4)  Enable's 
help  information  is  exceptional  (15:129);  and,  5)  with  pro- 


ductivity  in  mind,  the  June  24,  1986  issue  of  PC  Magazine 
wrote : 

The  Enable  database  manager  includes  strong 
relational  capabilities  and  a  procedural  language, 
and  it  ranks  with  some  of  the  best  standalone 
programs .  It  is  well  designed,  easy  to  use, 
generally  quite  fast...  (15:129). 

From  the  above  considerations,  the  authors  selected  ENABLE 

for  the  thesis  work.  The  next  step  in  the  process  is  to 

identify  and  precisely  define  the  problem.  Chapter  IV  shows 

the  difference  between  the  planned  storyboard  and  actual  DSS 

that  resulted  from  using  ENABLE. 


IV.  Flight  SchsdullnE  fiSS 

This  chapter  presents  the  differences  between  the 
planned  and  actual  scheduling  DSSs.  The  authors  built  the 
DSS  around  the  kernel  system  identified  in  Chapter  III.  The 
kernel  was  identified  as  matching  a  student  with  an  instruc¬ 
tor.  This  DSS  collects  the  information  necessary  to  do  this 
matching  and  presents  the  scheduler  with  lists  to  select  a 
student  or  instructor.  The  main  effort  was  to  build  as  much 
of  the  actual  storyboard  as  was  possible  in  the  time  avail¬ 
able.  The  DSS  differs  from  the  desired  storyboard  due  to 
technological  limitations  and  lack  of  programming  time.  The 
DSS  consists  of  three  sections: 

1 .  Menus 

2.  Spreadsheets 

3.  Databases 


The  authors  started  programming  from  the  storyboard  but 
soon  realized  that  the  actual  program  would  have  to  be  dif¬ 
ferent.  ENABLE  could  not  exactly  create  each  storyboard 
screen  in  every  detail,  therefore  the  authors  needed  to 
employ  a  different  representation.  Some  of  the  menus  in  the 
storyboard  were  not  used  while  others  were  newly  created 
The  following  table  lists  the  originally  planned  menus  and 
compares  them  to  the  current  DSS  menus  The  following  sec- 
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tiona  proba  any  diffarancaa  between  the  planned  and  currant 
menus  with  a  discussion  as  to  how  the  discrepancy  evolved. 

TABLE  4 . 1 

Comparison  of  Planned  and  Current  DSS  Menus 


PLANNED 

DSS  MENUS 

CURRENT 

MENU  STATUS 

Main  Menu 

Revised 

Daily  Event  Update 

Pending 

Student  Time  Line 

Pending 

Course  Changes 

Unchanged 

Unplanned 

Personnel  Availability  List 

Unplanned 

Wing  Lines  Input  Prompt 

Unplanned 

Created  Shell  Date  Prompt 

Note:  Pending  menus  Indicate  the  planned  DSS  menus  are 

not  part  of  the  key  kernel  system  and  have  not  been 
created.  Unplanned  menus  are  those  menus  which  were 
not  decision-oriented ,  but  memory  aids  to  prompt  the 
user  for  various  inputs. 

It  * "  MflLOU-  The  planned  main  menu  (Figure  4.1),  differs 
from  the  actual  menu  (Figure  4.2)  employed  in  the  OSS  due  to 
system  software  limitations.  ENABLE ' s  inability  to  interact 
freely  between  spreadsheets  and  databases  led  the  authors  to 
deal  only  with  spreadsheets .  Although  the  original  main 
menu  would  have  worked  as  planned,  the  authors  opted  to 


A.  TOMORROW’S  SCHEDULE 

B.  Priorities 

C.  Student  Avail 

D.  Instructor  Avail 

E.  Print 

F .  TODAY ’ S  SCHEDULE 

G.  Daily  Update 
INPUTS 

Students 

H.  Availability 

I.  Assigned  Inst 

J.  Instructor 

K.  Lines 

L.  Simulator 

M.  Academic 

N.  Duties/Meetings 
TIME  LINE 

O.  Class  TimeLine 

P.  Student  TimeLine 
COURSE  CHANGES 

Q.  Syllabus  Changes 

R.  Class  Changes 

S.  QUIT 


Figure  4.1.  Planned  Main  Menu 


Figure  4.2.  Actual  Main  Menu  Hierarchy 


remain  within  the  spreadsheet  environment.  This  allowed 
access  to  the  resident  macro  commands  for  simplicity  and 
speed.  The  user  invokes  this  menu  in  the  same  manner  as  the 
planned  menu. 

Dal ly  Event  Update .  The  daily  event  update  menu,  which 
updates  the  event  and  prerequisite  databases,  was  not  a  part 
of  the  key  kernel  system.  A  lack  of  programming  time  did 
not  permit  the  building  of  this  menu. 

Student  Time  Line .  The  student  time  line,  which 
depicts  a  student’s  progress  relative  to  his  syllabus  event 
flow,  was  outside  the  scope  of  the  kernel  system.  ENABLE’s 
ability  to  display  student  progress  graphically  is  excel¬ 
lent.  Once  a  DSS  method  is  developed  to  track  student 
progress,  the  display  and  graphics  will  assist  the  user  to 
make  decisions.  Appendix  F  shows  an  example  of  the  graphic 
capability  using  a  set  of  fictitious  students  and  time  line 
data  points. 

Course  Changes .  The  planned  course  changes  menu 
(Appendix  F)  remains  unchanged.  Although  not  a  part  of  the 
key  kernel  system,  this  menu  may  be  integrated  into  the  DSS 
at  a  later  date,  once  a  database  containing  prerequisites  is 
developed . 

Personnel  Availability  List .  This  menu  evolved  due  to 
the  need  to  update  the  personnel  availability  database  for 
extended  (more  than  one  day)  periods  of  time.  Critical  to 
the  scheduling  process  itself,  this  menu  allows  inputs  of 


personnel  leave,  DNIF,  and  TD7  events.  The  scheduler  may 
change  the  status  of  each  event  when  notified. 

Wing  Lines  Input  Prompt .  This  menu,  shown  in  Appendix 
F,  prompts  the  user  to  insert  the  wing  lines  data  diskette 
into  the  Z-248’s  B  drive.  The  authors  developed  the  menu 
because  the  Z-248  needs  the  disk  in  place  to  automatically 
process  the  wing  data.  Otherwise,  personnel  are  forced  to 
type  the  data  into  the  system. 

Created  Shell  Data  Prompt .  As  a  follow-on  to  the  wing 
lines  input  prompt,  once  the  user  creates  a  new  shell  he 
must  save  it  in  a  date  format  for  use  by  the  kernel  system. 
This  menu,  depicted  in  Appendix  G,  prompts  the  user  to  input 
the  shell  as  a  date.  It  then  automatically  saves  this  shell 
schedule  in  a  kernel -usable  file.  Each  shell  schedule’s 
file  name  is  the  date  the  DSS  uses  to  retrieve  that  file. 

Because  of  ENABLE'S  inability  to  freely  interact 
between  spreadsheets  and  databases,  the  authors  decided  to 
deal  strictly  with  spreadsheets  for  simplicity,  speed,  and 
flexibility.  As  such,  the  actual  DSS  incorporates  databases 
into  spreadsheets .  The  following  table  compares  the  planned 
and  current  DSS  databases . 

Student  and  Instructor  Databases .  For  the  reasons  men¬ 
tioned  above,  the  DSS  included  these  needed  databases  into 
the  Availability  spreadsheet  (Appendix  H) . 


TABLE  4.2 


i 

Comparison  of  Planned  and  Current  DSS  Databases 

i 


PLANNED  DSS 

CURRENT  DSS 

DATABASES 

DATABASES 

Student 

Changed  to  Spreadsheet 

Instructor 

Changed  to  Spreadsheet 

Syllabus  Events 

Pending 

Inputs / S tuden t / Avai labi 1 i ty# 

Pending 

Inputs/Student /Assigned 

Instructors# 

Pending 

Inputs/ Instructor# 

Changed  to  Spreadsheet 

Inputs /Academic# 

Changed  to  Spreadsheet 

Inputs /Duties -Meetings# 

Changed  to  Spreadsheet 

Course  Changes/Syllabus# 

Pending 

Course  Changes/Class* 

Pending 

Note:  Pending  databases  indicate  the  planned  databases 

are  not  part  of  the  key  kernel  system  and  have  not 

been  created.  Asterisked 
input  forms. 

items  (*)  are  database 

Syllabus  Evanta  Database .  A  lack  of  programming  time 
did  not  allow  the  authors  to  construct  the  database.  This 
database,  although  not  a  part  of  the  kernel  system,  will 
ensure  the  student  is  on  the  proper  scheduled  syllabus 
event . 

Inputs / Instructor  Input  Ear JB-  Figure  4.3  shows  the 


planned  input  form  for  the  instructors.  Figure  4.4  shows 
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434th 

INPUTS  /  INSTRUCTOR 

INSTRUCTOR  NAME 

ADD  DELETE 

STATUS : 

RED  DOT 

RCO 

SOF 

FLT  CDR 

BIG  3 _ 

FCF 

AVAIL: 

DNIF 

(Y/N) 

TDY 

(Y/N) 

LEAVE 

(Y/N) 

OTHER 

DATE 

DO  YOU 

WISH  TO  MAKE  ANOTHER  CHANGE? 

_  (Y/N) 

[FI ]  -  HELP 

Figure  4.3.  Plannsd  Instructor  Input  Form 


IP 

NAMES 


ALLAG  * 
AMDEC 
BECKG  » 
BECKW  • 
BO  HAM  • 
CASEK  » 
DANIJ  * 
DAWSV 
DOELJ  * 
DONAM 
FRAN Q  • 
FREDJ  • 
FBEIJ 
FUSSJ  » 
a  HO  SR 
HXLTC  » 
HUMSD  » 


LETTER  OF  X’S  AND  QUALIFICATIONS 


RANK  CP  FLT  CAT  EXP  UIPIP  UIPRD  FLTLD  RDIP  RBIP 


IP  B 
IW  C 
IP  A 
IP  A 
IP  C 
IP  A 
IP  C 
IP  B 
IP  C 
IP  A 
IP  D 
IP  C 
IP  D 
IP  B 
IP  B 
IP  A 
IP  B 


Figurs  4.4.  Actual  Instructor  Dstsbsss 
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the  actual  input  form.  The  planned  database  is  a  question- 
and- answer  input  to  a  database.  In  contrast,  the  actual 
database  is  a  listing  of  all  pertinent  data  for  the 
scheduler.  In  the  actual  presentation,  the  user  deals 
directly  with  the  data  (rather  than  automatically  when  using 
the  input  form)  because  the  spreadsheet  format  was  used. 

Inputa/Academic  Input  Form.  Figure  4.6  merges  the 
planned  academic  input  form  (Figure  4.5)  with  the 
duties/meetings  input  form.  The  reason  for  the  integration 
is  the  change  to  spreadsheet  format  (as  previously 
mentioned) . 


434  th 

17  OCT  86 

INPUTS 

/  ACADEMIC 

CLASS 

INSTRUCTOR 

START  TIME 

END  TIME 

GST-07M 

Fenno 

0800 

1300 

G0R-88B 

Heinrichs 

0800 

1000 

GOR-88B 

Heinrichs 

1400 

1000 

— 

— 

QUIT 

CF1  ] 

-  HELP 

Figure  4.5.  Planned  Academic  Input  Form 


SIM  TIME 

STUD 

INSTR 

ACADEMICS 

CLASS 

INSTR  START  END 

OPS  SUP 

STUD 

time" 

INSTR 

top"three 

— 

SOF  AM  PM 

FCF 

P  _  S 

RCO 

Figure  4.6.  Actual  Academic/Dut ies-Meetings  Input  Form 


DUTIES:  SIMULATORS  TIME  INSTRUCTOR  STUDENT 


DUTY  SWINE  TIME  INSTRUCTOR  TIME  STUDENT 


SOF  AM  _  PM _ P _ S _  _  CHANGE  TIME 

RCO  ~  _  __ 

FCF  PRIMARY _  STANDBY _  _ 

MEETINGS:  AIRCREW  STUDENT  INSTRUCTOR  OTHER:  _ 

START  TIME  END  TIME 


QUIT 


CF1 ]  -  HELP 


Figure  4.7. 


Planned  Duties-Meetings  Input  Form 


Figure  4.9  id  the  actual  ’spreadsheet  format  used  in  the  DSS . 
Neither  the  planned  nor  actual  formats  automate  the  input 
process  into  the  database. 

Inputs /Duties -Meetings  Input  Form.  Figure  4.7  above 
shows  the  planned  shell  to  schedule  duties  and  meetings. 

The  next  section  compares  the  planned  and  current  uses 
of  the  spreadsheet  portion  of  ENABLE. 


Spreadsheets 


TABLE  4.3 

Comparison  of  Planned  and  Current  DSS  Spreadsheets 


PLANNED  DSS 
SPREADSHEETS 

CURRENT  DSS 
SPREADSHEETS 

Tomorrow’s  Schedule 

Unchanged 

Today's  Schedule 

Unchanged 

Time  Line/Class 

Pending 

Unplanned 

Avai labi 1 i ty 

Unplanned 

New  Schedule  (ZNEWSCH) 

Unplanned 

Temporary  Schedule  (ZATEMP) 

Note:  Pending  spreadsheets  indicate  the  planned 

spreadsheets  are  not  part  of  the  key  kernel  system 
and  have  not  been  created.  Unplanned  spreadsheets 
are  those  spreadsheets  which  are  needed  to  make  the 

DSS  workings  transparent  to  the  user. 

Tomorrow*  a  Schedule .  As  described  in  Chapter  III, 
Tomorrow's  Schedule  is  a  part  of  the  kernel  system.  The 
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screen  presentation  is  currently  the  same  as  planned  in  the 
storyboard  (see  Appendix  F) .  The  completed  capabilities  of 
this  schedule  are  those  that  are  part  of  the  kernel  system. 

Today ’ s  Schedule .  Today’s  Schedule  (see  Appendix  F)  is 
currently  the  same  as  planned  in  the  storyboard.  Since 
Today’s  Schedule  is  a  completed  form  of  Tomorrow’s  Schedule 
(see  above),  the  capabilities  are  the  same.  The  user 
updates  Today’s  Schedule  when  a  deviation  occurs  as  a  record 
of  the  completed  events. 

Time  Line/Clads .  Since  student  syllabus  events  are  not 
a  part  of  the  key  kernel  system,  the  DSS  does  not  display 
the  class  time  line.  Although  ENABLE  has  a  very  capable 
graphics  software  package,  it  cannot  generate  the  graphs 
without  the  data.  Presentations  will  occur  once  developers 
integrate  the  syllabus  track  database  into  the  DSS. 

Instructor  Availability.  Figure  4.8  shows  the  actual 
spreadsheet  database  for  availability  of  instructors. 

ZHEWSCH.  The  authors  created  this  unplanned  spread¬ 
sheet  to  house  the  coding  and  formulae  necessary  for  con¬ 
structing  new  schedules  from  the  wing  line  input  disk.  The 
storyboard  did  not  account  for  programming  considerations, 
only  final  screen  presentations .  Thus,  users  needed  a 
method  to  transfer  wing  lines  data  into  a  usable  format. 

ZATEMP .  This  spreadsheet  is  a  temporary  completed 
shell  created  from  ZNEWSCH  that  is  awaiting  assignment  of  a 


name  (date) . 


Figure  4.8  Actual  Instructor  Availability  Spreadsheet 

Chapter  V  presents  the  author's  conclusions  and  recom¬ 
mendations.  These  conclusions  will  include  findings  for  the 
scheduling  DSS  and  recommendations  for  adaptive  design  in 
general . 
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Concluaions 

This  thesis  built  a  Decision  Support  System  (DSS)  using 
off  the  shelf  software  (ENABLE)  for  use  in  scheduling  at  the 
479«h  Tactical  Training  Wing.  The  DSS  is  friendly  enough  to 
allow  non- techni cal ly  oriented  users  to  use  the  DSS  without 
learning  ENABLE  .  However,  modification  of  the  program  will 
require  learning  ENABLE.  This  DSS  assists  a  scheduler  in 
the  process  of  matching  instructors  to  students  and  decon¬ 
flicting  their  schedules.  Furthermore,  the  DSS  reads  the 
wing  scheduling  data  file  and  builds  a  shell  f or  the  duty 
scheduler  in  two  minutes  on  a  Z-248  microprocessor.  The  DSS 
automatically  fills  in  a  deconf 1 iction  spreadsheet  for  the 
scheduler.  Finally,  at  the  end  of  the  day,  thi3  DSS  will 
help  crisis  management  at  the  squadron  level. 

This  chapter  has  two  parts.  The  first  part  is  conclu¬ 
sions  and  recommendations  for  the  squadron  DSS.  The  second 
section  discusses  DSS  adaptive  design  conclusions  and 
recommendations . 

&BA£iii£  Scheduling  £££ 

Cone  1  us i ons .  This  DSS  saves  a  scheduler  time  over  the 
current  situation  of  maintaining  grease  boards  by  using  com¬ 


puterized  databases  and  spreadsheets  for  the  manual  tracking 


process  (e.g.,  this  DSS  replaces  three  of  the  six  grease- 
boards  listed  in  Chapter  I).  These  spreadsheets  include  the 
capacity  to  sort  by  availability  (i.e.,  personnel  missing 
because  of  leave,  TDY,  or  DNIF) .  The  DSS  also  provides  a 
list  of  available  IPs  and  students  from  which  to  select  when 
scheduling.  In  addition,  the  DSS  automates  the  deconflic- 
tion  process. 

Due  to  screen  size  and  resolution  limitations,  the 
display  cannot  present  all  of  the  information  a  scheduler 
needs.  However,  this  DSS  displays  up  to  00  flights  on  one 
screen  and  the  remainder  of  the  information  (simulators, 

Duty  Hog,  etc.)  on  another  screen.  With  the  touch  of  one 
key,  the  DSS  will  display  any  information  the  scheduler 
currently  has  access  to. 

Programming  The  DSS  screens  evolved  from  the  ROMC 
memory  aid  requirement  plus  the  user’s  need  to  employ  vari¬ 
ous  portions  of  the  DSS  at  will.  The  DSS  capitalizes  on 
several  ENABLE  features.  The  DSS  primarily  uses  the  spread¬ 
sheet  portion  for  graphic  capability  and  speed.  The  hierar¬ 
chical  menus  used  in  the  scheduling  DSS  allow  easy  selection 
of  any  desired  function.  He  can  also  select  the  MAIN  MENU 
from  any  screen  using  the  Alt-FlO  key.  Should  the  user  have 
any  questions  about  the  DSS  functions,  he  may  ask  the  system 
for  help. 

The  need  to  include  a  help  function  stemmed  from  our 


own  questions  about  ENABLE.  On-line  help  and  informational 


prompts  are  «v«i ltbl*  wh 1 1 •  using  ths  088  Ths  D8S  ussr ' s 
unuil  (Appendix  H)  provides  details  About  ths  available 
help  functions  Another  feature  that  eeses  the  user'DSS 
interface  is  the  application  of  a  mouse 

Menu-driven,  mouse-operated  software  is  easier  for  a 
new  user,  especially  in  the  spreadsheet  application  soft 
ware  This  DSS  uses  mouse  hardware  and  software  for  greater 
friendliness  and  simplicity 

Future  Work  The  authors  base  the  following  proposals 
on  their  research  and  extensive  scheduling  experience  This 
thesis  lists  the  proposals  in  order  of  priority 

The  first  proposal  is  to  computerise  the  monthly 
Instructor  duties  in  a  database  When  a  scheduler  creates  a 
shell,  the  OSS  would  search  the  database  and  include  monthly 
duties  on  the  schedule.  The  initial  shell  could  include 
these  Inputs  when  created 

Another  proposal  is  to  computerize  the  student  training 
board  in  a  database.  The  computer  could  reference  the 
database  to  find  out  which  event  the  student  was  on  Fur¬ 
ther,  the  computer  could  update  the  database  depending  on 
the  completed  events  in  the  day’s  schedule.  Reference 
Appendix  0  for  suggested  database  relations. 

In  addition  to  the  above,  develop  a  way  to  check  pre¬ 
requisites  against  the  syllabus  flow.  The  computer  could 
check  to  see  if  a  student  had  his  prerequisites  done  accord- 
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inf  to  tha  syllabus.  As  ths  schsdulsr  sslscts  a  studant  for 


an  avant,  tha  databasa  could  ra call  which  avant  ha  was  on. 

Moraovar .  this  thasis  proposas  adding  tha  ability  to 
daconflict  acadasics ,  dutlas/maatlngs ,  simulators,  ate.  to 
tha  cosputar iiad  daconf 1 iction  board.  Tha  daconf 1 lction 
board  should  includa  al l  dutias  that  aach  sambar  must  par- 
fora  tha  naxt  duty  day. 

Tha  naxt  proposal  is  to  davalop  a  way  to  match  instruc¬ 
tor  qualifications  to  a  syllabus  rids  and  studant  (a.g.,  ACM 
qualification).  Tba  cosputar  should  ba  abla  to  match  an 
instructor  with  a  studant 1 s  naads  according  to  what  tha  syl¬ 
labus  raquiras  This  thasis  proposas  tha  addition  of  a 
modal  to  suggast  to  tha  schadular  a  match  of  Instructor  to 
studant 

A  furthar  proposal  is  davalop  a  dynamic  databasa  to 
contain  all  of  tha  lnforsMtion  raqulrad  to  schadula.  For 
axa*q>la,  if  a  studant  fails  a  rlda,  tha  DSS  should  flag 
futura  conf 1 icts/praraquisl tas  using  tha  updatad  informa¬ 
tion.  This  databasa  should  includa  tha  information  sug- 
gastad  abova .  In  addition,  it  should  lntarfaca  quickly  with 
tha  display  madlum  and  bring  up  tba  raqulrad  or  raquastad 
information  quickly  to  ba  tranaparant  to  tha  usar . 

£LSfi  and  Adapt iva  Dasisn  in  Qanaral 

Storyboard  .  Concant  Mapping  ,  and  AdAptl  V  Dl Al-gP  ■  Tha 
usa  of  storyboarding,  concapt  mapping,  and  adaptiva  dasign 


form  an  extremely  powerful  methodology  for  development  of 
DSSs .  Storyboarding  identifies  and  defines  requirements  for 
a  DSS.  Concept  mapping  identifies  the  key  kernel.  Task 
analysis  (Figure  3.5),  the  last  part  of  concept  mapping, 
clearly  centralized  the  importance  of  the  instructor- to- 
student  matching.  Adaptive  design  is  an  iterative  approach 
to  development  of  the  key  kernel  and  implementation  of  the 
DSS. 

Storyboard .  The  storyboard  is  an  excellent  tool  to 
identify  requirements.  By  defining  the  problem  visually, 
the  storyboard  evolves  during  the  early  stages  of  the  defi¬ 
nition  process.  As  users  update  their  requirements,  the 
storyboard  should  reflect  the  changes.  The  storyboard  shows 
the  ideal  system,  while  time,  technological,  and  monetary 
constraints  may  limit  the  actual  DSS.  The  authors  started 
programming  from  the  storyboard  but  soon  realized  that  the 
actual  program  would  have  to  be  different. 

Adaptive  Design.  Lack  of  available  thesis  time  and  TDY 
funds  limited  the  use  of  adaptive  design  to  the  first  itera¬ 
tion  of  development.  Lack  of  current  user  feedback  in  the 
field  would  have  resulted  in  the  development  of  this  DSS  in 
isolation,  but  fortunately,  the  builders  were  also  experi¬ 
enced  users.  Once  the  builders  created  a  prototype,  testing 
and  evaluation  by  the  users  at  Holloman  was  necessary  to 
continue  adaptive  design.  Unless  co-located,  user  feedback 
is  hard  to  get  and  usually  impossible  due  to  only  telephone 


conversations  (no  Z-248  or  money  for  TDY  was  available) .  A 
possible  methods  for  information  transfer  could  be  by  tele¬ 
phone  modem  or  mail  a  floppy  disk. 

During  programming  the  storyboard  evolution  continues, 
requirements  definition  evolves  for  the  complete  DSS ,  but 
the  actual  programming  involves  only  the  key  kernel.  The 
key  kernel  is  the  essence  of  the  decision  process.  The  ker¬ 
nel  evolves  once  the  users  evaluate,  modify  and  evaluate  it 
again  (see  Appendix  J  for  recommendations  on  evaluation) . 
Adaptive  design  demands  user  feedback  to  grow  around  the 
user’s  needs. 

These  authors  conclude  that  the  best  way  to  do  adaptive 
design  is  on-site  in  the  users’  organizational  environment. 
Immediate  feedback  would  be  available  to  the  builders  from 
the  most  current  users.  Eventually,  with  easy-to-use 
software  tools,  users  will  be  able  to  perform  adaptive 
design  and  apply  it  to  their  specific  DSS. 

Learning  ENABLE  took  a  majority  of  the  programming 
time.  To  be  an  effective  programmer  in  ENABLE  required 
approximately  a  month  and  a  half  of  learning  effort  for  two 
programmers.  Each  aspect  of  ENABLE  required  tutorials  and 
training  to  become  familiar  with  it.  The  problem  with  deal¬ 
ing  with  new  technology  software  is  that  the  form  of  many 
capabilities  you  want  included  in  a  program  is  unclear  from 
the  start.  No  clear-cut  solutions  exist.  Therefore  keeping 
an  open  mind  is  essential  during  this  type  of  unstructured 


work.  Many  questions  «roi«  at  this  point  about  how  the 
scheduling  program  was  to  work,  if  it  would  work  at  all1  In 
retrospect,  the  best  approach  would  be  to  learn  the  software 
capabilities  entirely  before  making  any  decisions  about  how 
something  was  to  work.  Appendix  A  contains  a  complete 
discussion  of  program  development. 
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only  the  kernel  nortlon  of  vnur  program  before  atartinS  on 

■  Programming  efforts  should  concentrate  on 
the  key  kernel.  The  authors  included  some  nice-to-have 
peripherals  that  were  not  necessary  according  to  the  concept 
map  development.  In  building  the  key  kernel,  the  software 
influenced  adaptive  design. 

The  type  of  hardware  and  software  a  builder  is  familiar 
with  influences  his  thinking  about  DSS  program  design  (e.g., 
IBM  versatility  and  speed  versus  Macintosh  pull  down  menus, 
ease  of  use,  and  graphics  capability).  The  type  of  hardware 
used  must  support  the  rapid  prototyping  portion  of  adaptive 
design . 

Sapid  prototyping  is  best  done  on  a  dedicated  machine 
(preferably  with  a  hard  drive).  This  thesis  effort  found 
that  working  at  home,  instead  of  competing  for  CPU  time  at 
work,  resulted  in  far  greater  productivity.  Most  large 
software  programs  require  frequent  shifting  of  the  floppy 
disks  between  the  drives  (e.g.,  ENABLE  requires  six  disks) . 
Productivity  increases  by  having  greater  speed  and  larger 


aaaory  within  tha  coaputar  .  Taaaing  up  in  groups  also 
incrsaats  productivity. 

Synsrglam  in  dsvsloping  ths  DSS  la  praaant  avan  at  tha 
two-parson  laval.  Planning,  dasigning,  laarning,  and  pro- 
graaasing  of  DSSs  a rm  bast  dona  in  taasu  of  two  or  aora.  Ona 
parson  Bay  provida  naw  and  diffarant  parspactivas  to  othars 
in  tha  taaa.  Furtharaora,  laarning  naw  softwara  is  aasiar 
in  groups  of  two  or  aora  than  individually. 

Making  tha  OSS  workings  transparant  to  tha  usar 
(without  lntarrupting  his  dacision  procass)  raquiras  a  larga 
amount  of  affort.  ENABLE  can  ba  aada  transparant  to  tha 
usar.  Howavar ,  tha  buildar  spands  tha  aajorlty  of  his  tlaa 
asking  his  work  transparant,  rath ar  than  furtharlng  tha 
prograa's  prograss .  This  is  not  bad  bacausa  DSS  trans- 
parancy  of  tha  DSS  structura  is  nacassary  for  succassful 
iaplaaantatlon  and  usar  f riandl lnass .  In  susasry ,  usar 
accass  to  tha  data  and  aodals  bus t  ba  as  aasy  as  possibla 
through  affactiva  dialogua. 

Softwara  salactlon  aay  not  rasult  in  tha  idaal  product 
for  tha  DSS.  Por  instanca,  tha  authors  chosa  ENABLE  bacausa 
that  was  what  tha  and  usars  would  usa ,  not  bacausa  it  was 
tha  bast  product.  Shown  balow  ara  tha  authors’  considara- 
tions  for  choosing  softwara  (listad  in  ordar  of  importanca): 

1.  Aval  labia  Coapatibla  Hardwara 

2.  Softwara  Packaga  Faaturas 

3.  Cost 

4.  Usar  Paaliiarity 

5.  Easa  of  Training  and  Softwara  Usa 


Tha  Boat  important  rtcoanwndation  ia  to  continua  to 
•volva  tha  karnal  DSS  through  tha  itarativa  adaptiva  daaign 
procaaa  of  building,  taating,  modification,  and  ao  on  (for 
an  axplanation  of  adaptiva  daaign  aaa  Chaptar  I).  Outlinad 
naxt  ara  raconmandationa  on  how  to  continua  tha  avolution  of 
tha  DSS . 

1 .  Find  a  champion 

2.  Appoint  a  rafaraa 

3.  Craata  a  ataaring  group 

4.  Minimisa  organisational  changaa  and  atraaaaa 

9.  Train  uaara 

0.  Documantat ion 

7.  Continuad  aupport  and  planning 

l  nn .  Find  ona  paraon  dadicatad  to  tha  idaa  of  a 
computarixad  DSS.  diva  that  paraon  tha  total  raaponaibi 1 i ty 
and  authority  ovar  tha  davalopmant  and  ioq>lamantation  of  tha 
DSS.  Allow  thia  paraon  to  guida  tha  implamantation ,  •valua¬ 
tion  and  modification  of  tha  ayatam.  Tha  authora  racomoand 
that  whan  tha  champion  goaa  PCS  tha  naw  champion  hava  at 
laaat  ona  month  of  ovarlap. 

Rafaraa .  Thia  paraon,  a  third  party,  objactiva  partic¬ 
ipant,  Judgaa  which  raaourcaa  or  modi f icationa  ara  committad 
to  tha  projact  naxt  (aaa  faadback  notaa  from  aquadron  uaara 
balow) 

Staaring  group .  Tha  ataaring  group  ahould  guida  tha 
lmplaamntation  and  furthar  davalopmant  of  tha  Schaduling 
Program  and  ita  uaa .  Tha  authora  raconnand  tha  ataaring 
group  includa  tha  Aaa  itant  Daputy  Commandar  of  Oparationa, 


a  wing  scheduler,  the  wing  computer  manager ,  all  of  the 
chief  squadron  schedulers,  and  all  of  the  squadron  computer 
managers.  The  steering  group  should  meet  monthly  throughout 
the  implementation  phase  of  the  DSS .  After  the  referee 
deems  appropriate,  bi-monthly  meetings  are  recommended. 
Additional  meetings  are  conducted  as  problems  arise. 

Minimi Organizational  ChanSes  And  Stresses .  The 
implementation  and  use  of  the  scheduling  program  should  not 
create  or  delete  any  jobs  existing  in  the  479*K  Tactical 
Training  Wing.  The  aim  of  the  steering  group  should  be  to 
minimize  organizational  stresses  during  testing  and 
implementation . 

Training  of  Peers .  Each  user  should  have  a  thorough 
and  complete  checkout  before  using  the  scheduling  program. 
Therefore,  each  squadron  should  establish  academic  classes 
before  the  use  of  the  scheduling  program.  The  author  rec¬ 
ommend  the  training  be  done  at  the  squadron  level  because 
each  squadron  will  use  the  program  to  schedule  differently. 

Docu— nUtion .  The  champion  and  each  squadron  should 
docusient  feedback  from  the  users.  The  DSS  documents  are: 

1.  Feedback  Notes  from  Squadron  Users 

2.  Hookbook 

Coatlnutd  Support  and  Planning .  The  referee  will  field 
any  complaints/suggestions  and  decide  their  merit,  present¬ 
ing  his  recommendations  to  the  steering  group.  The  schedul¬ 
ing  program  evolves  as  more  worthwhile  suggestions  are  used. 


70 


This  continued  support  and  planning  is  ssssntial  to  the 
adaptive  design  process. 

Feedback  Motes  Squadron  Vftra-  ENABLE 

includes  an  excellent  word  processor.  As  a  user  has  a  prob¬ 
lem,  he  should  document  it  on  the  spot.  The  user  could  then 
finish  scheduling  and  report  the  problem  to  the  referee  or 
squadron  small  computer  manager.  The  champion  gathers  all 
feedback  and  prioritizes  the  worthwhile  changes  to  the 
DSS(s).  Then,  the  steering  group  (with  the  referee’s 
approval)  decides  on  which  change  to  include  in  the  DSS . 

Hookbook .  The  hookbook  contains  future  plans  and 
ideas  for  the  DSS.  The  champion  documents  both  his  and  oth¬ 
ers'  inputs/ ideas  on  3x5  notecards  (Appendix  I).  The  cham¬ 
pion  should  not  discard  any  idea  because  implementation  can 
not  occur  immediately.  The  purpose  of  the  hookbook  is  not 
to  discard  any  worthwhile  feedback.  The  champion  sorts 
through  a  listing  of  worthwhile  ideas  from  the  )-ookbook  to 
see  which  idea  could  be  used  next.  This  process  of  collec¬ 
tion  in  the  hookbook  and  sorting  to  find  the  next  idea  is 
important  for  the  champion. 

EilUtl  Reoommendati  on  The  authors  recommend  the  con¬ 
tinued  automation  of  the  scheduling  system  at  Holloman.  The 
enthusiasm  and  drive  present  in  the  479**  TTW  will  ensure 
the  continued  evolution  of  a  DSS.  With  consideration  and 
care,  the  computer  will  make  the  479**  scheduling  system  the 
best  in  the  Tactical  Air  Force' 
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APPENDIX  A 


Program  DevoLgpaaat 

The  authors  wrote  the  program  as  If  thay  comp la tad  aach 
atap  before  going  on.  A  battar  pictura  would  ba  an  itera- 
tiva  approach,  wbara  aach  atap  adds  to  tha  undaratanding  of 
the  pravioua  stapa.  Tha  programmar  may  avan  go  back  and  re¬ 
vise  pravioua  atapa.  Programming  aach  atap  ia  raraly  cob* 
plataly  dona  in  one  atap. 

Tha  authors  quickly  complatad  all  tutorials.  A  review 
waa  adequate  to  get  started  programming  until  thay  mat  a 
specific  problem.  Throughout  tha  development  process ,  tha 
authors  used  the  documentation  to  help  aolva  specific  prob¬ 
lems  . 

ENABLE  is  a  large,  alow  program  unless  you  have  a  hard 
drive.  ENABLE  requires  Six  floppy  diaka  to  run  tha  program. 
Using  tha  floppy  diaka  requires  constant  changing,  in  and 
out,  of  tha  diak  drives  during  programming.  This  constant 
changing  of  floppy  disks  was  a  slow,  cumbersome  process. 
Using  a  hard  drive  decreased  ENABLE  run  time  tremendously 
and  not  switching  disks  is  a  pleasure.  Tha  authors  esti¬ 
mated  tha  program  turn-around  time  increased  tan-fold.  In¬ 
stallation  of  ENABLE  on  AFIT’s  IBM  PC-AT  made  available  two 
places  to  develop  tha  scheduling  program:  Work  and  home. 

Tha  authors  did  tha  major  part  of  tha  development  at  home 


but  if  an  idea  formed  at  work,  the  IBM  PC-AT  was  immediately 
available  to  work  on. 

The  next  progress  on  development  was  moving  through  the 
documentation  page-by-page.  The  authors  explored  the  Data 
Base  Management  (DBM)  system  using  the  documentation  much 
like  a  tutorial.  They  accomplished  all  of  the  examples  in 
the  DBM  section  of  the  manual  until  familiar  with  that  spe¬ 
cific  section.  The  authors  also  kept  the  Quick  Reference 
Quide,  a  pamphlet  summarizing  all  the  commands,  handy  for 
any  word  processing  questions.  In  addition,  they  placed  the 
ENABLE  keyboard  overlay  on  the  keyboard. 

Then,  the  authors  constructed  a  database  using  actual 
aircrew  qualification  data.  They  considered  a  qualification 
database  essential  to  the  scheduling  program.  This  database 
construction  process  is  basically  a  learning  process  for  the 
software;  the  authors  did  little  actual  programming  toward 
the  final  product  at  this  stage.  The  following  three  stages 
of  development  were  iterated  several  times  before  completion 
of  this  learning  stage. 

1)  Database  definition  was  very  straightforward.  Af¬ 
ter  K  day  programming  a  good  lesson  was  that  a  little  time 
spent  up  front  in  planning  would  go  a  long  way.  For  exam- 
pi*.  it  is  a  good  idea  to  standardize  the  format  of  data  the 
user  will  enter.  By  using  the  same  field  names  and  format, 
the  programmer  may  reduce  errors  and  data  transfer  between 
databases  will  be  possible. 


2)  The  Input  Form  is  the  screen  that  the  user  sees 
when  he  inputs  data  to  the  database.  Since  the  user  would 
interface  directly  with  this  screen,  help  messages  should  be 
available  for  each  input  line  and  on-line  for  general  help 
(more  on  help  messages  below) .  The  Input  Form  must  match 
with  the  database  definition,  so  a  change  to  database  defi¬ 
nition  meant  a  change  in  the  Input  Form  also.  Furthermore, 
each  line  could  be  custom  designed  for  restriction  of  input. 
For  instance,  an  input  line  could  contain  only  a  date  or 
numbers  or  only  letters.  If  the  input  line  received  any 
unauthorized  inputs,  an  error  message  would  result.  The  er¬ 
ror  message  is  custom-designed  for  each  input  line. 

3)  The  Database  display  is  also  custom-designed.  The 
user  may  sort  and  list  in  any  desired  order.  The  computer 
screen  may  display  whatever  is  input  to  the  database. 

The  development  and  use  of  help  messages  became  an  un¬ 
expected  aspect  of  the  learning  process.  The  authors  could 
design  the  input  line  to  be  case-sensi ti ve ,  so  JACK  is  dif¬ 
ferent  from  Jack.  The  EXACT  planning  of  what  the  builder 
wants  the  user  to  input  is  imperative  at  this  stage.  The 
use  of  the  following  four  general  rules  helped  programming 
tremendous ly : 


1. 


Give  onscreen  help  instructions.  Don’t  make  ths 
ussr  search  for  a  key  to  help,  when  you  can  write 
it  on  the  screen. 

2.  Have  an  error  message  ready  in  case  of  error. 

3.  Have  the  cursor  jump  to  the  next  field  if  neces¬ 
sary  . 

4.  In  general,  design  your  help  exactly  the  way  you 
want  it  BEPORE  YOU  START.  A  little  planning  goes 
a  long  way. 

At  this  point  the  scheduling  program  was  taking  on  the 
form  of  interaction  with  a  database.  The  problem  with  deal¬ 
ing  with  new  technology  software  is  that  the  form  of  many 
capabilities  you  want  included  in  a  program  is  unclear  from 
the  start.  No  clear  cut  solutions  exist.  Therefore  keeping 
an  open  mind  is  essential  during  this  type  of  unstructured 
work.  Many  questions  cropped  up  at  this  point  about  how  the 
scheduling  program  was  to  work,  if  it  would  work  at  all! 
Although  in  retrospect,  the  best  approach  would  be  to  lrarn 
the  software  capabilities  entirely  before  making  any  deci¬ 
sions  about  how  something  was  to  work. 

The  next  development  was  copying  American  Standard  Code 
for  Information  Interchange  (ASCII)  into  the  database.  AC- 
SII  is  a  Code  that  represents  each  character,  number  and 
symbol  on  a  computer  screen  by  an  8-bit  binary  number . 

Since  the  479%*  Wing  delivered  the.  daily  flying  sorties 
times  to  the  squadron  on  a  floppy  disk,  the  scheduling  pro¬ 
gram  would  need  to  be  able  to  read  that  file  from  the  floppy 
disk.  The  documentation  showed  that  it  was  possible  to  copy 
ASCII  into  a  database.  Upon  investigation,  ENABLE  could 
copy  ASCII  from  an  external  file  into  the  database  portion. 
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Then  from  the  database  portion  into  any  other  part  of  EN¬ 
ABLE. 

The  final  form  of  the  startup  macro  does  the  following 
process : 

1.  Beads  wing  data  into  database 

2.  Reads  from  database  into  spreadsheet 

3.  Calculates  takeoff  and  land  time 

4.  Resizes  spreadsheet 

5.  Constructs  initial  scheduling  screen 

0.  Brings  up  main  menu 

The  use  of  macros  capability  occurred  next  in  the  de¬ 
velopment  of  the  scheduling  program.  Macros  are  computer 
code  that  execute  certain  actions  in  ENABLE  automatically. 
The  authors  needed  to  hide  the  complex  portions  of  the  pro¬ 
gram  from  the  casual  user  for  the  scheduling  program  to  be  a 
success.  Non-technical ly  oriented  personnel  should  be  able 
to  use  the  scheduling  program.  So  an  attempt  to  have  the 
program  process  information  by  itself  involved  the  use  of 
macros.  ENABLE  excelled  in  the  formation  and  execution  of 
macros.  ENABLE  could  create  a  macro  while  the  programmer 
did  the  keystrokes.  For  instance,  while  the  programmer 
loaded  ASCII  into  the  database,  the  computer  was  recording 
the  keystrokes.  The  keystrokes  were  put  into  a  file  that 
ENABLE  could  executed  at  any  later  time  that  would,  now,  au¬ 
tomatically  load  ASCII  into  the  database  when  the  macro  was 
invoked . 

An  important  discovery  was  the  ability  to  use  a  mouse 
in  ENABLE.  A  mouse  is  a  hand-held  pointing  device  for  the 
computer.  The  discovery  came  at  a  time  when  simplicity  was 


•specially  important.  Program  acceptance  and  use  could  de~ 
pend  on  the  user-f riendliness  of  the  scheduling  program. 

The  software  used  to  activate  a  mouse  in  LOTUS  SYMPHONY  also 
worked  for  ENABLE. 

The  next  development  demonstrated  the  evolutionary  de¬ 
velopment  of  the  main  menu  in  the  storyboard.  Starting  on 
the  main  menu  was  a  mistake  because  of  the  many  iterations 
the  authorse  were  to  perform.  The  main  menu  (MM1)  initially 
designed  was  the  one  that  was  storyboarded .  The  Main  Menu 
covered  the  whole  computer  screen  and  involved  a  series  of 
hierarchical  expanded  menus.  The  next  main  menu  (MM2)  cov¬ 
ered  only  the  right  hand  portion  of  the  screen  and  included 
all  of  the  possible  selections  in  our  program.  The  authors 
discarded  MM2  as  their  approach  changed  from  a  menu-  driven 
database  to  a  spreadsheet.  The  discovery  that  macros  would 
only  work  inside  spreadsheet  or.  database  (but  not  both) 
shifted  the  approach  to  a  spreadsheet.  The  current  main 
menu  (MM3)  is  a  series  of  hierarchical  expanded  menus  at  the 
top  of  a  spreadsheet.  The  best  thins  to  do  in  adaptive  de- 
ei«n  is  to  work  on  only  the  kernel  portion  of  vour  program 
hefore  startinS  on  the  peripherals. 

Next,  both  programmers  spent  about  K  day  going  over  the 
storyboard  to  give  form  and  function  to  the  picture.  They 
considered  each  storyboard  in  detail.  The  authors  also  gave 
each  item  in  the  storyboard  some  detail  about  how  the  item 


was  to  work,  given  what  they  learned  of  the  software.  For 


instance,  the  programmers  defined  the  QUIT  function  on  each 
screen  to  where  it  would  send  the  user  to,  once  selected. 
They  also  considered  how  each  item  was  to  connect  with  other 
items  in  the  menu  and  in  other  menus.  All  21  proposed 
screens  were  gone  over  in  detail.  A  curious  thing  happened, 
both  programmers  realized  a  lot  needed  changing  to  conform 
with  what  was  possible  and  realizable.  The  authors  did  the 
storyboard  as  a  first  cut.  The  programmers  realized  they 
did  not  need  certain  items  or  could  not  do  them  at  present. 
And  a  few  more  screens  were  necessary  to  complete  the  pro¬ 
gram.  Therefore,  what  the  programmers  could  do  started  to 
differ  from  the  storyboard  at  this  point. 

Just  a  note  here  about  the  storyboard  but  more  detail 
in  Chapter  III.  The  storyboard  is  the  ideal,  no  technologi¬ 
cal  constraints  requirements  definition.  What  the  program¬ 
ming  could  accomplish  was  quite  different.  Once  the  pro¬ 
grammers  chose  the  software  and  started  the  programming,  the 
screens  conformed  more  to  specific  software  limitations. 

The  storyboard  had  been  an  excellent  requirements  definition 
tool.  Basically,  the  storyboard  had  transformed  a  decision 
process  into  computer  screens  inputs  and  outputs.  Now  that 
the  programming  had  begun,  the  storyboard  was  of  the  form  of 
the  ideal  program  while  the  program  took  on  the  form  of  what 
was  technologically  possible. 

At  this  point,  the  programmers  set  up  details  like  col¬ 
ors  in  all  the  screens  and  automatic  startup.  Colors  were 

A-7 


m 

m 


.?  V 

•Sv 

■*»'**« 

.‘■*s 


jgjjj 

m 

'.;*J 


m 

4 

t*{b 

:S 


1 


ft 


& 


set  in  the  default  profile.  Also,  to  make  the  program 
transparent  to  the  user,  ENABLE  will  invoke  a  starting  macro 
that  sends  the  user  to  the  opening  menu  of  the  scheduling 
program  instead  of  the  opening  menu  of  ENABLE. 

Next,  the  programmers  set  up  the  required  window  con¬ 
figuration.  Shown  below  is  the  listing  of  how  the  open  win¬ 
dows  were  planned  to  be  in  the  scheduling  program. 

1.  Tomorrow's  schedule 

2.  Today’s  schedule 

3.  Other  information  as  needed 

The  inability  of  the  macros  to  work  outside  the  origi¬ 
nating  functions  (e.g.,  spreadsheet,  database,  word  process¬ 
ing)  changed  the  program  considerably.  The  plan  at  this 
point  was  to  use  a  spreadsheet  as  the  display  medium  to  the 
user  and  use  a  database  for  the  manipulation  of  data.  How¬ 
ever,  the  macros  would  not  work  across  the  two  types  of 
functions.  For  instance,  if  a  macro  was  invoked  in  the 
spreadsheet  and  moved  into  another  window,  say  a  database, 
the  macro  would  stop  executing.  The  need  for  user  trans¬ 
parency  and  ease  of  use  drove  the  program  into  a  single 
functional  area.  The  programmers  chose  the  spreadsheet 
functional  area  for  its  graphics  capability  and  speed  over 
the  database. 

Each  programmer  specialized  at  this  point.  One  pro¬ 
grammer  moved  into  the  file  and  menu  area.  The  other  auto¬ 
mated  the  internal  functions  in  the  scheduling  spreadsheet 
i tsel f . 
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The  most  pressing  question  at  this  point  was  how  to 
structure  the  system  and,  more  specifically,  the  file  layout 
during  presentation  of  the  DSS.  This  task  may  be  broken 
down  into  four  areas: 

1.  File  structure  (what  is  displayed). 

2.  File  access  (macros). 

3.  File  manipulation  (Spreadsheet-avail). 

4.  Menu  generation. 

The  first  area  was  the  file  structure  (what  was  to  be 
displayed).  The  initial  plan  was  to  have  TODAY’S  SCHEDULE 
in  the  first  ENABLE  window.  TOMORROW’S  SCHEDULE  would  re¬ 
side  in  the  second  window.  The  third  window  would  contain  a 
dummy  macro  file  which  would  hold  the  window  in  reserve  for 
future  schedule  creation  tasks .  The  fourth  and  fifth  win¬ 
dows  would  display  instructor  and  student  availability  sta¬ 
tus  respectively.  Window  number  six  would  show  student 
event  prerequisites.  A  reserved  space  to  display  schedules 
other  than  TODAY’S  or  TOMORROW’S  would  be  in  the  seventh 
window,  while  additional  duties  for  the  last  schedule  dis¬ 
played  would  reside  in  the  last  (eighth)  window. 

From  working  with  the  large  spreadsheet  files  in  the 
various  windows,  the  authors  discovered  a  hardware  system 
limitation.  ENABLE  has  the  ability  to  work  with  only  two 
windows  of  large  spreadsheet  files  in  computers  fitted  with 
the  8088-series  microprocessor.  This  limitation  is  due  to 
the  availability  of  only  640,000  bytes  of  computer  random 
access  memory  (RAM) ,  of  which  ENABLE  uses  a  substantial  por¬ 
tion  (depending  on  the  size  of  the  files  being  manipulated). 


Because  of  this  limitation,  the  file  structure  forced  the 
placement  of  the  availability  database  in  the  first  window 
and  the  desired  schedule  in  the  second  window.  This  place¬ 
ment  was  what  the  users  would  need  as  a  minimum  to  schedule, 
given  the  availability  of  only  two  windows.  Once  the  pro¬ 
grammers  set  up  the  file  structure,  the  next  task  was  how  to 
access  these  files. 

File  access  for  this  DSS  encompasses  program  start-up 
and  file  retrieval.  ENABLE  provides  the  ability  of  using  a 
macro  to  start  up  the  OSS.  The  idea  was  to  start  ENABLE  au¬ 
tomatically  from  computer  turn-on  and  call  up  the  next  day’s 
schedule.  This  would  all  be  transparent  to  the  user,  of 
course.  Automatically  starting  ENABLE  was  a  simple  matter 
of  entering  a  BATCH  command  within  the  AUTOEXEC.BAT  file 
resident  on  the  computer.  This  command  also  includes  the 
name  of  the  macro  file  automatically  executed  once  ENABLE 
starts.  Appendix  I  contains  the  individual  macros.  A  char¬ 
acteristic  of  a  macro  is  that  it  executes  until  it  hands 
control  over  to  a  menu.  The  menu  may  contain  instructions 
to  continue  to  another  macro,  but  it  can’t  return  to  the 
original  macro,  unless  you  wish  to  start  the  macro  over 
again.  So,  the  start-up  sequence  includes  several  menus  in¬ 
tertwined  with  macros. 

The  start-up  sequence  involved  much  trial -and-error . 

It  began  with  trying  to  invoke  menus  from  macros  and  then 
link  the  menus  back  into  other  macros.  With  the  syntax  mas- 
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tered ,  Table  A. 1  lays  out  the  desired  start-up  sequence. 

Once  ENABLE  has  started  and  the  availability  spreadsheet  re¬ 
sides  in  the  first  window,  the  screen  presents  the  author 
credits  menu  for  two  seconds.  Then,  the  credits  menu  in¬ 
vokes  the  system  date  conversion  macro  in  the  availability 
spreadsheet.  This  macro  uses  the  current  date  resident  in 
the  computer  to  determine  what  day  it  is.  Then,  the  macro 
figures  out  which  date  would  be  the  next  day’s  schedule. 

For  example,  if  today  was  Friday  the  13***,  the  next  day 
would  be  Monday  the  16***.  The  date  retrieval  macro  takes 
over  after  this,  creating  a  new  macro  which  gets  the  next 
day's  schedule  and  places  it  into  the  second  ENABLE  window. 

Since  the  schedulers  must  have  the  most  up-to-date  in¬ 
formation  about  their  personnel ,  the  DM1F/TDY  menu  is  in¬ 
voked  to  query  the  user  as  to  their  status.  If  users  desire 
a  change,  the  system  updates  the  status  of  any  person (s). 
Once  personnel  availability  is  current,  the  system  transfers 
the  list  onto  the  current  scheduling  spreadsheet.  The  user 
now  has  all  the  current  information  from  which  to  schedule 
the  next  day’s  events.  Finally,  the  system  invokes  the 
spreadsheet’s  main  menu.  The  user  is  now  ready  to  start 
scheduling . 

The  most  complex  macros  involved  in  the  file  access 
functions  reside  in  the  availability  spreadsheet.  These 
file  manipulation  macros  include  system  date  conversion  and 
personnel  availability  update  capability.  The  system  date 


TABLE  A. 1 

DSS  Start-up  Sequence 


SEQUENCE 

FILE 

1. 

Start  ENABLE  from  computer 
turn-on . 

AUTOEXEC . BAT 

2. 

Place  availability  spreadsheet 
in  Window  #1 . 

«{0> .MCM 

3. 

Invoke  author  credits  menu. 

F.MNU 

4. 

Invoke  system  date  conversion. 

AVAIL. SSF 

5. 

Edit  date  retrieval  macro. 

«(1) .MCM 

6. 

Place  next  day’s  schedule  in 
Window  #2. 

*{2) .MCM 

7. 

Invoke  DNIF/TDY  menu. 

D.MNU 

8. 

Update  personnel  availability. 

AVAIL. SSF 

9. 

Transfer  current  availability 
to  the  schedule  in  Window  2. 

•{5} .MCM 

10. 

Qo  to  Window  #2  and  invoke  the 
main  menu  of  the  schedule. 

S{5) .MCM 

conversion  macro,  mentioned  above,  retrieves  the  date  from 
the  internal  computer  clock  and  transfers  that  date  into  a 
usable  form.  The  personnel  availability  macro  adjusts  the 
availability  spreadsheet  so  that  the  user  may  change  the 
status  due  to  leave,  DNIF,  TDY,  or  other  circumstances.  The 
macro  then  sorts  through  the  changes,  creating  a  list  of  un¬ 
available  personnel.  The  system  macros  take  over  to  trans¬ 
fer  this  list  to  the  current  schedule. 
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Following  the  stop s  in  Table  A.l,  the  start-up  macro 
then  generates  the  schedule's  main  menu,  found  on  each 
schedule  shell.  This  menu  generation  follows  the  menu  hier¬ 
archy  depicted  in  Figure  1.1.  The  macro  activates  when  the 
user  presses  the  [Shift-F103  and  Z  keys.  Currently,  because 
of  the  key  kernel  system,  the  only  active  portions  are  the 
add,  delete,  and  move  functions.  For  ease  of  use  and  be¬ 
cause  of  the  repetitive  nature  of  these  tasks ,  the  macro  ac¬ 
tivates  when  the  user  presses  the  [Shift-FlO]  and  A  keys. 

In  addition  to  the  schedule  spreadsheet  menu,  five  more 
menus  are  available.  The  first  menu  is  the  author  credits 
menu.  *  This  calls  the  DSS  ‘Flight  Scheduler*  and  lists  the 
author’s  names.  The  second  menu  overlays  a  prompt  over  the 
list  of  unavailable  personnel.  The  displayed  prompt  queries 
the  user  to  see  if  he  wishes  to  change  the  availability 
1 i 8 1 .  If  the  answer  is  yes,  the  menu  invokes  the  above-men¬ 
tioned  personnel  availability  macro.  If  not,  the  menu 
starts  the  macro  which  transfers  the  list  to  the  current 
displayed  schedule.  The  third  menu  prompts  the  scheduler 
for  changes  to  the  course  syllabus  tracks  or  student  syl¬ 
labus  assignment.  There  are  no  macro  commands  resident 
within  this  menu  as  it  is  not  a  part  of  the  key  kernel  sys¬ 
tem.  The  next  menu  prompts  the  user  to  insert  the  Wing 
lines  input  disk  into  the  computer’s  A  drive.  Once  done, 
the  menu  invokes  the  macro  which  transfers  the  line  informa¬ 
tion  to  a  newly  created  blank  shell.  The  last  menu  prompts 


the  user  to  sntsr  a  nans  for  the  new  shell.  This  name  will 
be  In  a  date  format  (e.g.,  20MAR)  so  the  DSS  may  call  up  the 
file  at  a  later  time. 

Building  the  menus  required  explicit  knowledge  of  EN¬ 
ABLE  and  it's  command  structure.  It  took  a  considerable 
amount  of  time  to  learn  how  the  menus  interacted  with  the 
macros  and  vice-versa.  Coloring  the  menus  took  time  as 
well;  the  effort  involved  time-consuming  trial -and-error 
methods  because  the  documentation  was  not  explicit. 

At  the  same  time  the  above  external  file  processing  was 
taking  place,  the  other  author  was  busy  building  the  inner 
workings  of  the  individual  schedules.  The  internal  program¬ 
ming  included  automating  the  selection  of  instructor  pilot 
names  and  student  names.  The  three  processes  decided  upon 
were  adding,  deleting  and  moving  a  name  from  one  portion  of 
the  schedule  to  another.  Furthermore,  the  programmers  con¬ 
sidered  completion  of  an  automatic  deconf 1 ict ion  sheet. 
Macros  were  used  to  automate  all  of  the  above  requirements. 

The  addition  macro  adds  a  name  to  the  schedule.  Since 
the  deconf liction  sheet  contained  a  list  of  all  the  instruc¬ 
tor  and  student  names,  a  window  opens  to  show  the  list  to 
the  user.  The  user  selects  a  name.  The  macro  takes  over  at 
this  point  by  doing  the  following: 

1.  Checks  to  see  if  the  time  slot  is  available  on  the 
deconf liction  sheet. 

2.  Puts  the  name  at  the  desired  position  on  the 
screen  if  the  time  slot  is  free  on  the  deconflic- 
tion  schedule. 

3.  Fills  out  the  deconf 1 iction  sheet. 
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Fig.  A. 1  Deconf 1 lotion  Sheet 


Additional  prompts  are  added  to  guide  the  user  through  the 
automatic  macro  executions. 

The  deletion  of  a  name  from  the  schedule  is  a  point  and 
press  process.  The  user  moves  the  cursor  over  the  desired 
name  to  delete  him  from  the  schedule.  Upon  execution,  the 
deletion  macro  takes  the  name  off  the  schedule  and  deletes 
that  time  slot  from  the  deconf 1 iction  sheet. 

The  move  macro  is  similar  to  the  above  processes,  com¬ 
bining  both  a  deletion  and  addition  process.  First,  the 
macro  deletes  the  desired  name  from  the  position  onscreen 
and  deletes  the  time  from  the  deconf 1 iction  sheet.  Second, 
the  process  is  exactly  like  the  addition  macro.  The  macro 
adds  a  name  to  the  desired  position,  if  the  time  is  open  on 
the  deconf 1 iction  sheet. 


A-  1 5 


APPENDIX  B 


Concept  Map  Formulation 


Appendix  B  contains  the  iterative  process  of  forming 
the  concept  map.  This  process  includes  the  first-cut  of  the 
desision  process  and  formation  of  the  main  decision  list. 
The  decision  list  is  then  ordered  and  placed  into  a  rough 
concept  map.  A  second-cut  of  the  decision  process  is  done 
culminating  in  the  actual  concept  map  formulation. 
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Figure  B.l.  Capt  Grechanik’s  First-cut  of  Decision  Process 
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Figure  B.2.  Capt  Trapp’s  First-cut  of  Decision  Process 
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Figure  B.4.  Ordered  Decision  List 
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Figure  B.8.  Second-cut  of  Decision  Process  (Iteration  #2) 


Figura  B.9.  Concept  Map  Formulation 
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APPENDIX  C 


Task  Analysis 


Appendix  C  contains  the  evolution  of  the  task  analysis. 
It  includes  a  basic  scheduling  overview  as  well.  This 
review  was  for  Capt  McFarren's  benefit  as  he  was  unfamiliar 
with  the  particulars  of  aircrew  training  scheduling.  This 
iterative  process  of  forming  the  task  analysis  results  in 
the  completed  depiction  shown  in  Figure  C.5. 


Figure  C.l.  Scheduler’s  Input  Sources 
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Figure  C.2.  First  Task  Analysis  Iteration 


/ps* 


Figure  C.3.  Second  Task  Analysis  Iteration 
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Figure  C.4.  Third  Task  Analysis  Iteration 
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Figure  C.5.  Completed  Task  Analysis 
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APPENDIX  D 
Data  Analysis 

Appendix  D  contains  ths  database  relations  used  for  the 
kernel  system.  The  figure  below  shows  the  data  variables 
and  the  screens  under  which  they  fall. 
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Figura  D.l.  Data  Analysis 


APPENDIX  E 


Feature  Chart  Evolution 

Using  ths  scheduling  screen  hierarchy  depicted  in  Fig¬ 
ure  3-7  and  the  database  relations  in  Appendix  D,  the  fol¬ 
lowing  portion  focuses  purely  upon  the  requirements  needed 
by  the  user.  This  appendix  describes  the  features  that  each 
screen  must  perform.  There  was  no  bias  towards  any  commer¬ 
cial  software  or  their  particular  capabilities  or  limita¬ 
tions.  This  process  reflected  the  user’s  needs  without  re¬ 
gard  to  any  technological  restraint.  Should  a  limitation 
occur  after  the  feature  chart  has  been  developed,  the  DSS 
will  have  to  be  modified  to  incorporate  as  much  as  possible 
within  current  commercial  software  bounds . 

Evolution .  The  evolution  of  the  system  via  the  feature 
chart  concentrates  on  the  overall  system  and  the  individual 
portions.  Each  category  is  important  because  it  is  from 
these  features  that  the  DSS  will  be  built.  To  view  the 
overall  picture,  the  feature  chart  for  the  system  is  dis¬ 
cussed  first. 

System.  The  system  itself  must  contain  several  fea¬ 
tures.  First,  it  must  link  the  data  bases  to  the  scheduling 
process  itself  so  that  it  becomes  interactive.  This  will 
ensure  the  user  works  with  the  most  current  and  accurate  in¬ 
formation.  Next,  the  system  must  deconflict  individuals  and 


event*  10  that  scheduling  two  people  for  th*  urn*  «v#nt  at 
tha  a am*  time  (or  on*  p*rion  for  two  *v*nta  at  th*  aam* 


time)  do**  not  occur.  With  th*a*  features  in  mind,  th*  fol¬ 
lowing  section#  focus  on  *ach  portion  of  th*  system. 

Main  Menu.  Referring  to  th*  scraan  hierarchy  (Fig.  3- 
7) ,  th*  first  faatura  addressed  was  th*  main  menu.  An  im¬ 
portant  characteristic  of  this  m*nu  was  to  be  able  to  access 
it  from  any  place  in  th*  DSS .  Once  activated,  it  should 
take  th*  user  to  any  other  portion  of  th*  system. 

Tomorrow*  a  Schedule .  The  next  item  considered  was  To¬ 
morrow’s  Schedule.  Th*  primary  feature  required  was  to  in¬ 
clude  a  full  day’s  flying  events  upon  a  single  screen  -  a 
limitation  which  currently  existed.  This  screen  must  con¬ 
tain  space  for  takeoff  time,  crew  nasas,  aircraft  configura¬ 
tion,  area  name,  mission  type,  and  comments  for  each  sortie. 
Also,  pop-up  windows  displaying  who  was  available  to  fly  was 
necessary.  These  windows  would  display  prioritized  lists 
from  which  th*  scheduler  would  choose  as  well  as  an  option 
to  change  th*  priority  used  to  create  the  lists.  These  fea¬ 
tures  should  resemble  th*  grease  boards  currently  in  us*. 

Today  *  s  Schedule .  The  features  mentioned  above  would 
be  Incorporated  into  Today’s  Schedule.  Th*  presence  of  this 
schedule  was  a  convenience  to  th*  user,  as  he  often  must 
change  it  when  daily  deviations  occur.  It  would  also  elimi¬ 
nate  th*  need  of  having  to  load  th*  schedule  from  th*  DSS 
files  each  time  a  change  was  needed. 
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Today’ a  Schedul e/Dai 1 v  Evtnt  Update ■  This  screen  would 
qusry  ths  ussr  as  to  whsther  or  not  Today's  Schsduls  events 


want  as  plannad.  It  would  than,  basad  upon  his  rasponsa, 
updata  tha  data  basa.  Tha  scraan  must  ba  abla  to  discarn 
tha  typa  of  avant ,  who  was  schadulad,  and  tha  raason  for  tha 
daviation. 

Inputs / S tudan t / Avai labl 1 i ty .  This  scraan  must  ba  capa¬ 
ble  of  adding  or  delating  student  events  which  affect  his 
scheduling  availability.  These  events  include  DNIF,  TDY, 
and  leave  and  tha  applicable  day(s).  Also,  tha  scraan  must 
have  tha  capability  to  enter  appointments  or  meetings  which 
may  span  hours  or  days . 

Inputs /Student/ Assigned  Instructors .  This  screen  must 
ba  abla  to  input  tha  instructors  a  student  is  assigned  to 
fly  with.  It  should  reference  tha  student's  class  and  pri¬ 
mary  instructor.  In  addition,  tha  scraan  should  have  space 
for  up  to  five  extra  assigned  instructors.  This  scraan  will 
primarily  ba  an  input  to  tha  data  basa  used  to  prioritize 
instructor  matching  to  students. 

Inputs/ Instructor .  This  scraan  is  essentially  tha  same 
as  Inputs/Student/ Avai labi 1 i ty ,  but  with  an  additional  fea¬ 
ture.  Tha  extra  feature  must  ba  abla  to  input  changes  to  an 
instructor's  qualification  data  basa.  These  qualifications 
would  include  rad  dot,  RCO,  SOF ,  flight  commander,  Big  3, 
and  functional  check  flight. 


Inputs/Academic .  In  the  same  manner  as  the  previous 
acreen,  the  primary  feature  would  be  to  update  or  change  an 

academic  meeting.  It  should  have  the  option  to  change  the 
availability  of  either  a  class  of  students,  instructor,  or 
both.  The  screen  should  reference  the  student  class,  date 
and  time  of  the  academic  meeting,  and  the  instructor  as¬ 
signed  to  teach. 

Inputs/Duties-Meetinf a .  This  screen  must  display  the 
numerous  additional  duties  and  meetings  which  occur  each 
day.  Also,  there  must  be  space  to  enter  instructor  or  stu¬ 
dent  names,  depending  on  the  type  of  duty.  Much  like  the 
schedule  screens  described  above,  this  screen  should  have 
the  pop-up  windows  displaying  choices  of  qualified  and 
available  individuals. 

liffll  Line/Class .  This  screen  must  be  able  to  graphi¬ 
cally  depict  the  time  line  for  a  student  class.  The  presen¬ 
tation  should  be  a  bar-type  graph  for  ease  of  analysis  show¬ 
ing  the  status  to  be  above  or  below  the  zero  (even)  level. 
The  screen  should  also  contain  a  numerical  representation 
for  individual  classes  as  well  as  the  date  of  the  last  up¬ 
date  . 

Time  Llne/Studen.t .  This  screen  must  be  able  to  graphi¬ 
cally  depict  the  time  line  for  each  student  in  a  class.  The 
presentation  should  be  a  bar-type  graph  for  ease  of  analysis 
showing  the  status  to  be  above  or  below  the  zero  (even) 


level . 


The  screen  should  also  contain  a  numerical  represen- 


tation  for  individual  students,  a  total  time-line  status  for 


the  class,  and  the  date  of  the  last  update. 

Course  Chang es / Sv 1 labus .  This  presentation  must  list 
the  specific  syllabus  track  under  revision.  Also,  it  must 
list  each  track  event  and  the  prerequisites  needed  to  accom¬ 
plish  that  event.  There  should  be  space  enough  for  at  least 
eight  prerequisites  for  each  event. 

Course  Changes/Class .  This  screen  must  be  able  to  add, 
delete,  or  change  the  members  of  a  student  class.  The  pre¬ 
sentation  should  display  the  students  with  their  assigned 
syllabus  track  and  an  indication  of  red  dot  status.  There 
should  be  a  date  showing  the  last  time  an  update  happened. 
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APPENDIX  F 


Storyboard 

The  actual  DSS  computer  screen  output  format  (storyboard) 
must  support  the  basic  premise  of  user  process  flexibility.  In 
other  words,  it  must  be  able  to  assist  users  with  varied  expe¬ 
rience  and  individual  techniques,  yet  not  be  cumbersome  to 
interpret  or  manipulate.  At  the  same  time  the  DSS  must  be 
powerful  enough  to  support  any  decision  sequences  the  user  may 
require.  The  latter  requisite  is  best  accomplished  using  an 
iterative  approach  over  a  period  of  time  with  the  user 
employing  the  DSS  and  relying  on  the  structure  of  the  kernel  to 
assist  him.  As  such,  the  authors  base  the  screen  output  format 
on  the  decision  process  and  kernel  identified  in  the  previous 
chapter . 

The  authors  use  the  ROMC  user-builder  interface  technique 
to  develop  the  storyboard.  ROMC  is  the  acronym  for  Representa¬ 
tion,  Operations,  Memory  aids,  and  Control  Mechanisms.  Each  of 
these  tools  enables  the  designer  to  translate  user  requirements 
into  DSS  components.  This  structure  allows  the  flexibility 
necessary  to  satisfy  both  the  user’s  needs  and  the  builder’s 
design  requirements.  The  storyboard  needs  these  tools  to  build 
effective  output  screens. 

Representation,  the  first  tool,  depicts  the  actual  screen 
presentation  needed  by  the  user.  This  data  representation  must 


satisfy  the  user's  needs  in  a  clear  and  concise  manner.  The 
order  of  the  representations  must  be  logical  as  well,  conform¬ 
ing  to  the  user's  decision  or  thought  process  sequence.  This 
last  thought  is  especially  important  because  the  OSS  should  not 
distract  the  user  as  he  thinks,  rather  it  should  ease  his  deci¬ 
sions  by  presenting  him  the  next  piece  of  information  when 
needed.  Should  the  user  require  closer  scrutinization  of  a 
particular  piece  of  data  or  focus  in  on  a  present  screen  por¬ 
tion,  manipulation  of  the  representation  may  be  necessary. 

The  second  tool,  operations,  enables  the  user  to  manipu¬ 
late  the  representations  on  the  screen  to  suit  his  individual 
technique.  This  may  take  the  form  of  actual  data  manipulation 
(e.g.,  sorting),  scale  change  (e.g.,  viewing  a  larger  or 
smaller  portion  of  the  screen)  ,  or  adding/deleting  various 
amounts  of  data  for  clarity  or  interpretation.  Of  course,  the 
user  accomplishes  these  operations  when  needed  so  as  not  to 
distract  his  thought  process. 

The  next  tool  used  in  designing  the  storyboard  is  memory 
aids.  These  helpful  reminders  guide  the  user  through  his  deci¬ 
sion  process  with  the  use  of  icons,  windows,  highlighted 
(colored)  information,  or  various  flags.  Memory  aids  remind  or 
warn  the  user  of  certain  decisions  at  specified  times. 

Finally,  control  mechanisms  are  interwoven  throughout  the 
entire  kernel,  enabling  any  user  to  skip  tedious  or  familiar 
processes.  Control  mechanisms  ease  movement  to  any  part  of  the 


kernel.  Control  mechanisms  may  take  the  form  of  selectable 
menus  or  predefined  function  keys. 

A  problem  facing  the  storyboard  itself  is  how  to  place  all 
of  the  necessary  information  on  the  screen  without  cluttering 
the  presentation.  The  easiest  way  to  present  the  information 


is  to  diagram  all  of  the  kernel  components  carefully.  The 
authors  arranged  and  grouped  these  components  in  a  logical 
manner  according  to  the  user’s  decision  process.  The  authors 
then  ordered  these  componenets  into  the  screen  design. 

Table  F.l  show  the  information  the  scheduler  needs  to  make 


a  schedule: 


TABLE  F . 1 


Needed  Scheduler  Information 


Tomorrow’s  schedule. 

Available  students. 

Available  instructors. 

Priority  considerations. 

Ability  to  print  schedule. 

Today's  schedule. 

Ability  to  update  events. 

Schedule  inputs. 

Flying  sortie  lines  from  wing 
Simulator  lines  from  wing. 

Student . 

Avai labi 1 i ty . 

Assigned  instructors. 
Instructor  Status. 

Academic  classes  and  instructors. 
Duties  and  meetings. 

Statistics . 

Time  line  by  class. 

Time  line  by  individual  student. 
Course  changes. 

Student  syllabus. 

Class  additions/deletions. 


rM 


This  information  is  best  presented  in  a  network  hierarchical 
fashion  (Figure  3.7).  Once  this  network  is  established,  the 


authors  may  design  the  storyboard  using  the  ROMC  tools  pre¬ 
viously  mentioned. 

Using  the  scheduling  screen  hierarchy  depicted  in  Figure 
3.7,  the  following  portion  will  focus  purely  upon  the  require¬ 
ments  needed  by  the  user.  There  will  be  no  bias  towards  any 
commercial  software  or  their  particular  capabilities  or  limita¬ 
tions.  This  is  to  reflect  the  user’s  needs  without  regard  to 
any  technological  restraint.  After  storyboard  development,  the 
DSS  will  have  to  be  modified  to  include  the  kernel  within 
current  commercial  software  bounds. 
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MAIM  MEMU 

Representation :  This  presentation  lists  all  of  the 

screens  in  the  scheduling  program  hierarchy.  The  screen  is 
compressed  to  the  right  of  the  page  to  allow  overlaying  of  any 
other  screen  without  hiding  information.  The  main  sub-headings 
are  shown  in  capitals. 

Operations :  The  user  employs  the  up  and  down  arrows  to 

select  one  of  the  categories.  Hitting  CENTER]  will  display  the 
selection.  As  users  gain  more  experience,  the  letters  along 
the  left  side  of  the  menu  will  activate  the  desired  selection. 

Memory  Alda :  As  the  user  scrolls  through  the  selections 
with  the  up  and  down  arrow,  a  one  line  prompt  appears  at  the 
bottom  of  the  screen  explaining  where  the  cursor  rests. 

The  major  categories  in  the  scheduling  program  hierarchy 
are  capitalized.  Further  subheadings  are  indented  and  not  all 
capitals  to  further  break  out  the  list  to  the  user. 

Control  Mechanisms :  Pressing  function  key  [FI]  brings  up 
online  help  on  the  screen.  Pressing  EF1]  again  gets  rid  of  it. 
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Figure  F.l.  Main  Menu 


TOMORROW'S  SCHEDULE 

Representation :  This  presentation  depicts  all  of  the 

flying  sorties  on  one  screen  for  ease  of  scheduling.  The  lower 
windows  will  overlay  the  screen  trying  to  hide  as  little 
information  as  possible. 

Operations :  The  user  positions  the  cursor,  via  arrow 

keys,  to  certain  items  of  the  schedule  (e.g.,  on  a  FCP  space). 

i 

Upon  selecting  STUDS  AVAIL,  a  prioritized  list  of  students  will 
appear  on  the  right  side  of  the  screen.  The  user  then  selects 
a  student  name.(  Upon  pressing  [ENTER],  the  student's  name  will 
be  placed  under  the  cursor.  Similar  operations  occur  upon 
selecting  INSTRUCTORS  AVAIL  and  PRIORITIES.  PRINT  will  print 
out  a  hard  copy  of  the  schedule.  QUIT  will  exit  the  scheduling 
program  after  saving  the  work. 

Memory  Aida :  As  each  option  is  selected,  a  one  line  ex¬ 

planation  appears  directly  below.  For  instance,  if  STUDS  AVAIL 
is  selected,  a  message  stating  'A  PRIORITIZED  LIST  OF  STUDENTS' 
will  appear . 

Control  Mai-han  1  gag ;  The  arrow  keys  will  move  the  cursor 
to  the  next  field.  The  information  may  be  entered  manually  by 
positioning  the  cursor  where  desired  and  typing  it  in.  Typing 
in  new  information  is  activated  either  by  the  [ENTER]  key  or 
selecting  one  of  the  fields  described  in  Operations.  The  [FI] 
key  brings  up  HELP  instructions  for  this  screen.  The  [F2]  key 
brings  up  the  MAIN  MENU. 
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Figure  F.2.  Tomorrow’s  Schedule 
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TODAY  •-S  SCHEDULE 


R»pr«a»ntation:  This  display  is  much  the  same  as  that  of 

TOMORROW'S  SCHEDULE.  The  type  ride  will  have  been  filled  in  as 
the  schedule  was  completed.  Names  will  be  present  in  the  un¬ 
derlined  spaces.  TODAY’S  SCHEDULE  will  be  a  copy  of  TOMORROW’S 
SCHEDULE  that  was  worked  on  the  day  before. 

Operations :  The  UPDATE  option  allows  the  scheduler  to  an¬ 

notate  any  deviations  that  occurred  on  TODAY’S  SCHEDULE.  This 
option  also  lets  the  user  research  any  past  schedule  to  find 
out  what  was  scheduled.  PRINT  allows  a  hard  copy  of  whatever 
is  on  the  schedule  at  that  time  to  be  printed.  The  QUIT  option 
saves  his  work  and  takes  the  user  back  to  the  MAIN  MENU.  Func¬ 
tion  key  CF1]  brings  up  instructions  on  how  to  use  the  schedule 
screen. 

Memory  Aids :  As  each  option  is  selected,  a  one  line 
explanation  appears  directly  below.  For  instance,  if  UPDATE  is 
selected,  a  message  stating  'Update  TODAY’S  SCHEDULE'  will 
appear . 

Control  Mftf!han<ann ;  The  arrow  keys  will  move  the  cursor 
about  the  screen  to  each  field.  The  user  will  be  able  to  enter 
information  in  two  ways.  First,  the  information  may  be  entered 
manually  by  positioning  the  cursor  where  desired  and  typing  it 
in.  Typing  in  new  information  is  activated  when  hitting  the 
CENTER!  key.  Second,  the  user  may  select  one  of  the  fields 
described  in  Operations.  The  [Fll  key  brings  up  HELP  instruc¬ 
tions  for  this  screen.  The  CF2]  key  brings  up  the  MAIN  MENU. 
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TODAY*  S  SCHEDULE  L  DAILY  EVENT  UPDATE 

Raprtuntation :  The  presentation  will  be  a  aeries  of 

questions  and  fillina.  Tha  (Y/N)  questions  will  hava  default 
values  so  the  user  may  simply  accept  tha  values  proposed  by  the 
program. 

Operations :  The  user  may  select  either  a  sortie,  simula¬ 

tor,  student,  or  classroom  activity,  and  give  the  reason  for 
the  deviation.  He  will  then  be  queried  as  to  the  accuracy  of 
his  inputs.  The  screen  will  further  prompt  him  for  additional 
deviation  occurrences. 

Memory  Aida :  The  user  is  always  prompted  as  to  the  accu¬ 
racy  of  his  inputs  and  if  he  wants  to  quit  or  continue. 

Control  Mechanisms :  The  arrow  keys  allow  movement  about 
the  screen.  Operations  upon  the  representation  consist  of 
filling  in  the  appropriate  entry  and  hitting  the  [ENTER]  key. 
Answering  NO  to  the  'DO  YOU  WISH  TO  MAKE  ANOTHER  CHANGE'  ques¬ 
tion  will  exit  to  TODAY’S  SCHEDULE.  The  [FI]  key  brings  up 
HELP  instructions  for  this  screen.  The  [F2]  key  brings  up  the 
MAIN  MENU. 


F-  1 1 


434th 


10  OCT  86 


TODAY’S  SCHEDULE  /  DAILY  EVENT  UPDATE 
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Figure  F.4.  Daily  Evant  Update 
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WING  LINES  INPUT  PROMPT 

Representation :  The  presentation  will  be  a  prompt  to 


insert  the  disk  containing  the  daily  wing  line  data. 

Operations :  The  user  is  queried  for  the  correct  disk. 

Memory  Alda :  The  user  is  prompted  for  his  inputs  and  his 
next  action. 

Control  Meghan l sms :  No  control  mechanisms  are  used  for 


this  screen. 
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Place  the  Wing  Disk 
containing  Flight  Shell 
Lines  into  the  A  drive 
of  the  Z-248.  Press 
ENTER  when  ready. 
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Figure  F.5.  Wing  Lines  Input  Prompt 
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INPUTS  L  STUDENT  L  AVAILABILITY 
Rapresentation:  The  student’s  name  and  whether  the  event 

will  be  added  or  deleted  comprises  the  initial  input  line  on 
the  screen.  A  vertical  list  to  include  DNIF,  TDY,  LEAVE,  and 
OTHER  event  type  follows  with  s tart/end  dates.  Another  OTHER 
event  line  is  included  with  start  and  end  times  for  a  specific 
date.  The  QUIT  option  allows  the  user  to  return  to  the  MAIN 


MENU. 


The  user  inputs  the  students  name  and  whether 


to  add  or  delete  his  name  from  one  of  the  availability  cate¬ 
gories  . 

Memory  Aids :  The  user  is  shown  most  available  categories 
on  the  screen.  Addition  or  deletion  and  student  name  are 


prompted  for. 

Control 


The  arrow  keys  will  move  the  cursor 


along  the  available  choices  while  the  [ENTER]  key  implements 
the  selection  (for  the  ADD,  DELETE,  DNIF,  TDY,  and  LEAVE 
entries  only).  The  rest  of  the  entries  must  be  input  before 
using  the  [ENTER]  key.  The  user  is  prompted  for  another 
change.  If  yes,  the  information  is  input  and  the  screen 
cleared  for  another  input.  If  no,  the  information  is  input  and 
the  user  is  returned  to  the  main  menu.  The  [FI]  key  brings  up 
HELP  instructions  for  this  screen.  The  [F2]  function  keys 
displays  the  MAIN  MENU. 
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Figure  F.6.  Student  Availability 
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IMEUTS  L  STUDENT  L  ASSISNED  INSTRUCTORS 

Representation:  The  student’s  name  is  listed  by  class. 

To  the  right  is  the  primary  and  secondary  assigned  instructor's 
name.  Space  for  additional  instructors  is  provided  in  the  ad¬ 
jacent  columns.  The  QUIT  option  allows  the  user  to  return  to 
the  MAIN  MENU. 

Operations :  The  user  will  input  the  primary  and  secondary 

assigned  instructors.  The  user  is  then  prompted  for  another 
input  with  'DO  YOU  WISH  TO  MAKE  ANOTHER  INPUT?’.  If  yes,  the 
information  is  saved  and  the  screen  cleared  for  another  input. 
If  no,  the  information  is  input  and  the  user  is  returned  to  the 
main  menu. 

Memory  Aids :  The  headings  are  listed  directly  above  the 
input  slots.  One  line  information  prompts  will  be  displayed  at 
the  bottom  of  the  screen  when  the  cursor  rests  on  specific  lo¬ 
cations.  When  the  cursor  rests  below  the  PRIMARY  slot  the 
prompt  ’Enter  the  students  Primary  Instructor’  will  be  at  the 
bottom  of  the  screen.  CF1]  -  HELP  is  listed  at  the  bottom  of 
the  screen. 

Control  Meehan  jams :  The  CF1]  key  brings  up  HELP  instruc¬ 
tions  for  this  screen. 
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Figure  F.7.  Student  Assigned  Instructor 
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The  instructor's  name  and  addition  or 


deletion  is  the  initial  input  line  on  the  screen.  The  user  is 
prompted  for  a  STATUS  or  AVAIL  input.  A  vertical  list  to 
include  DNIF,  TDY,  LEAVE,  and  OTHER  event  type  follows  with 
start/end  dates.  Another  OTHER  event  line  is  included  with 
start  and  end  times  for  a  specific  date.  The  lower  prompt 
allows  the  user  to  continue  or  return  to  the  MAIN  MENU. 

Operations:  This  screen  changes  the  status  or  availabil¬ 

ity  of  a  instructor  in  the  database.  The  Instructors  name  may 
be  added  or  his  status  may  be  changed.  The  user  is  then 
prompted  for  another  input  with  "DO  YOU  WISH  TO  MAKE  ANOTHER 
CHANGE?’.  If  yes,  the  information  is  saved  and  the  screen 
cleared  for  another  input.  If  no,  the  information  is  input  and 
the  user  is  returned  to  the  main  menu. 

Memory  Aids:  One  line  of  information,  specific  to  the 
cursor  location,  will  be  displayed  as  the  cursor  is  moved  from 
slot  to  slot. 

Cpatral  Mechaniama :  The  [FI]  function  key  brings  up  HELP 
instructions  for  this  screen. 
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Figure  F.8.  Instructor  Status 


INPUTS  L  ACADEMIC 

Representation :  The  data  will  be  entered  in  vertical 

columns  titled  using  the  shown  information  headings.  The  QUIT 
option  allows  the  user  to  return  to  the  MAIN  MENU. 

Operations :  The  data  will  be  used  in  a  database  to  decon¬ 

flict  the  academic  instructors  and  student  classes 

Memory  Alda :  The  columns  are  titled  appropriately  to 
assist  the  user. 

Control  Maghaniam* ;  The  arrow  keys  will  move  the  cursor 
along  the  available  choices.  The  entries  must  be  typed  before 
using  the  [ENTER]  key.  The  [FI]  key  brings  up  HELP  instruc¬ 
tions  for  this  screen. 
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Figure  F.9.  Academic  Inputs 


F-22 


.  y"  >  w 


DUTIES  will  be  the  first  category  to 


include  inputs  for  SOF ,  RCO ,  RAMP  supervisor,  functional  check 
flights  (FCFs) ,  'BIG  3,'  and  DUTY  SWINE  entries.  SOF  has  space 
for  AM  or  PM  duty  as  well  as  Primary  or  Secondary  slots.  RCO 
and  DUTY  SWINE  have  START/END  times.  All  entries  have  spaces 
for  INSTRUCTOR  names.  In  addition,  STUDENT  name  slots  are 
provided  for  DUTY  SWINE.  MEETINGS  comprise  the  rest  of  the 
screen.  The  type  of  meeting  (AIRCREW,  STUDENT,  INSTRUCTOR, 
OTHER,  SOF  RCO,  RAMP,  FCF ,  or  SAFETY  is  selected  first.  The 
managerial  level  is  selected  next  WING.  SQUADRON,  FLIGHT,  or 
CLASS).  Finally,  the  START/END  times  are  noted.  The  QUIT 
option  allows  the  user  to  return  to  the  MAIN  MENU. 

Operations :  As  the  cursor  is  placed  upon  a  STUDENT  or 

INSTRUCTOR  slot,  a  window  with  a  list  of  available  choices  for 
the  particular  duty  will  appear. 

Memory  Aids :  The  labels  are  listed  vertically  to  stand 
out  to  the  user. 

Control  Meohenlsms :  The  arrow  keys  will  move  the  cursor 
along  the  available  choices  while  the  [ENTER]  key  carries  out 
the  selection  for  all  except  START/END  times,  STUDENT/ INSTRUC¬ 
TOR  names,  and  OTHER.  The  rest  of  the  entries  must  be  typed 
before  using  the  [ENTER]  key.  The  [FI]  function  key  brings  up 
HELP  instructions  for  this  screen. 
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Figure  F.10.  Duties/Meetings 
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TIME  LINE  L  CLASS 


Representation :  This  presentation  will  graphically  show 

all  of  the  student  classes’  timelines.  The  E  will  denote  the 
class  that  is  right  on  schedule  while  the  horizontal  bars  will 
depict  classes  that  are  ahead  or  behind  their  timeline. 

Operations :  The  graph  will  be  displayed  when  the  user 

selects  'Class  Timeline'  from  the  MAIN  MENU. 

Memory  Aida :  The  class  names  are  depicted  along  the  left 
side  of  the  graph. 

Control  Mechanisms :  The  [FI]  function  key  brings  up  HELP 
instructions  for  this  screen. 
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Figure  F.ll.  Class  Timeline 
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TIME  LIME  L  STUDENT 


Representation :  This  screen  will  overlay  the  main  menu 

and  select  the  student  class  the  user  wants  to  display. 

Operations :  Selection  of  a  class  will  display  the  indi¬ 

vidual  students  and  their  time  line  progress. 

Memory  Aida :  A  one  line  information  prompt  will  appear 
just  below  the  Select  Class. 

Control  Mechanisms :  The  [FI]  key  brings  up  HELP  instruc¬ 
tions  for  this  screen. 


F-27 


Figure  F.12.  Student  Timeline 
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COURSE  CHANGES 

Representation :  This  screen  will  prompt  the  user  for: 

1)  Syllabus  Change  and  the  Track  or 

2)  Class  Change,  the  Class  and  the  Action. 

Operations :  Selecting  either  of  the  above  options  moves 

the  user  to  one  of  the  next  two  screens.  Typing  in  the  CLASS 
name  will  retrieve  an  old  class  or  create  a  new  one  with  that 
designation.  Further  selection  moves  the  user  to  the  appropri 
ate  screen. 

Memory  Aids :  The  only  possible  inputs  will  be  listed  on 
screen  (e.g.,  (A,B,C)). 

Control  Meehan i « urn  :  One  line  information  prompts  will 
appear  when  the  cursor  is  on  a  specific  slot.  The  [FI]  key 
brings  up  HELP  instructions  for  this  screen. 
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COURSE  CHANGES 


Syllabus  Change: 


Track: 


Class  Change: 


(A,B ,C) 


Class  : 

Action:  (A,D,C) 


MAIN  MENU 


TOMORROW’S  SCHEDULE 


Student  Avail 
Instructor  Avail 
Priorities 
Print 

TODAY’S  SCHEDULE 


Daily  Update 
INPUTS 

Flight  Shell 
Students 

Aval labi 1 i ty 
Assigned  Inst 
Instr.  Status 
Academic 
Duties /Meetings 
TIME  LINE 


Class  TimeLine 
Student  TimeLine 
COURSE  CHANGES 


Syllabus  Changes 
Class  Changes 
QUIT 


Figure  F.13.  Course  Change  Menu 


COURSE  CHAHflES  L  SYLLABUS 

Representation:  A  column  of  specific  events  lies  on  the 

left  portion  of  the  screen.  Beside  each  event  is  space  to  en 
ter  a  number  of  prerequisites  needed  to  accomplish  that  event 
In  addition,  a  QUIT  choice  is  included  to  enable  the  user  to 
exit  to  the  MAIN  MENU  if  desired. 

Operations :  This  screen  will  allow  changes  to  the  syl¬ 

labus  database. 

Memory  Aida :  The  syllabus  track  that  the  user  has  se¬ 
lected  will  be  displayed  on  the  screen.  The  events  will  be 
listed  as  they  appear  in  the  syllabus. 

Control  Manhantama :  The  arrow  keys  will  move  the  cursor 
along  the  available  choices  while  the  [ENTER]  key  implements 
the  typed  in  selection.  The  [FI]  key  brings  up  HELP  instruc¬ 


tions  for  this  screen. 
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434th 

COURSE  CHANGES  /  SYLLABUS 


10  OCT  86 


EVENT : 


PREREQUISITE! 


SYLLABUS:  TRACK  A 


FI  TR2 
F2  FI 


F3  F2 
F4  F3 


F5  F4 
F0  F5 


TSIM2 


QUIT 


CPI  3  -  HELP 


COURSE  CHANGES 

Syllabus  Change: 

Track : 

( A ,  B  ,  C) 

Class  Change: 

Class : 

Action : 

( A  ,  D  ,  C) 

Figure  F.14.  Syllabus  Changes 
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COURSE  CHANGES  L  CLASS 

Representation :  A  column  of  specific  students  lie  on  the 

left  portion  of  the  screen.  Beside  each  student  is  his  spe¬ 
cific  syllabus  TRACK.  Immediately  adjacent  is  a  note  to  re¬ 
flect  his  red  dot  status,  if  any.  In  addition,  a  QUIT  choice 
is  included  to  enable  the  user  to  exit  to  the  MAIN  MENU  if  de¬ 
sired  . 

Operations :  A  pop-up  window  appears  in  the  lower  right  of 

the  screen  to  enable  the  user  to  input  changes  or  create  a  new 
class  of  students. 

Memory  Aida :  The  class  that  the  user  is  changing  is  dis¬ 
played  at  the  right  side  of  the  screen. 

Control  Mechanisms:  The  up  and  down  arrow  keys  will  move 
the  cursor  along  the  available  choices  while  the  [ENTER]  key 
implements  the  typed-in  selection.  The  [FI]  key  brings  up  HELP 


instructions  for  this  screen. 


SYLLABUS 
STUDENT :  TRACK 

Youm  A 

Ribit  B 

Bohunk  C 

Rambo  C 

Adrian  B 

Squaty  A 

Radblood  A 

QUIT 


434th 


COURSE  CHANGES  /  CLASS 


10  OCT  86 


RED  DOT 
STATUS : 
N 

Y 
N 
N 

Y 
N 
N 


CLASS : 


GST-87M 


NAME 

SYLLABUS 


ADD  RED  DOT 
DEL  RED  DOT 
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APPENDIX  Q 


Program  User 1 a  Manual 

Start-up. 

This  manual  describes  what  tha  usar  will  actually  sea  on 
the  computer  screen  and  how  he  should  uae  the  screens .  When 
the  computer  is  turned  on,  the  resident  macros  initially  start 
tha  Flight  Scheduler  (FS)  program.  The  DNIF/TDY  change  prompt 
(Figure  Q.l)  appears  above  the  latest  list  of  personnel  who  are 
unavailable  (or  will  be  unavailable)  for  scheduling.  This  menu 
asks  the  user  if  the  people  listed  in  the  various  categories 


Shown  below  is  a  list  of  those  individuals  who  are  DNIF, 
TDY,  or  on  LEAVE.  This  list  will  be  used  to  display 
available  personnel. 


Do  you  wish  to  change  the  list?  M  Y 


DNIF 


LEAVE 


OTHER 


BECXQ 

HUNSD 

BOHAM 

DANIJ 

LINNR 

FREDJ 

DAWSV 

QROSR 

MAYRL 

MINEG 

Figure  Q.l.  DNIF/TDY  Change  Prompt 


Should  be  changed.  The  red  letters,  N  (for  no)  and  Y  (for 
yes),  appear  at  the  end  of  the  prompt  with  M  highlighted.  If 
the  user  does  not  wish  to  change  the  availability  list,  he 
presses  the  [ENTER]  key,  and  the  program  proceeds.  If  he  wants 
to  change  the  listing,  he  presses  the  left  or  right  arrow  keys. 
The  Y  is  now  highlighted.  To  start  the  list  changes,  the  user 
presses  the  [ENTER]  key  and  the  program  continues. 

If  the  user  wanted  to  change  the  availability  list,  the 
spreadsheet  in  Figure  0.2  appears.  The  user  may  now  move 
freely  about  the  screen  using  the  arrow  keys.  To  add  an  X  to 


VABVIVG: 

DO  NOT  WRITE  IN  THE  AVAIL  COLUMN  AS  THIS  DESTROYS  THE  FORMULAS 
NEEDED  TO  CREATE  THE  LISTING! 


the  list,  the  user  positions  the  cursor  across  from  the  desired 
name  and  under  the  desired  column.  He  then  types  an  X  and 
presses  the  [ENTER]  key.  To  remove  an  X,  the  user  simply 
presses  the  space  bar  followed  by  the  [ENTER]  key.  Once  the 
user  makes  all  the  changes,  he  simultaneously  presses  the 
[Shift]  and  [F9]  keys,  then  the  [S]  key.  This  action  causes 
the  program  to  create  an  updated  availability  list. 


Vote:  If  more  than  one  X  lies  beside  a 

crew  name  (e.g.,  DNIF  and  OTHER),  the 
computer  places  the  name  under  the 
right-most  category  (i.e.,  OTHER). 


0-2 


After  the  user  updates  the  availability  list,  the  program 
transfers  the  updated  list  to  the  next  day's  schedule.  The 
main  menu  then  appears  at  the  top  of  the  spreadsheet. 


IP 

NAMES 
ALLAG 
ANDEC 
BECKG 
BECKJ 
BECKW 
BOHAM 
CASEX 
DANIJ 
DAWSV 
DEAUC 
DOELJ 
DOMAM 
PRANG 
FREDJ 
FRKIJ 
FUSSJ 
GABLG 
GROSR 
HELTC 
HUFFD 
HUNSD 
XL  I  NS 
KOKAA 
LINNR 
MARVC 
MAYRL 
MCGBT 
MILLS 
MINEG 


AVAILABILITY 


DNIF  LEAVE  TDY  OTHER  AVAIL 


X 


X 

X 


m 


x 


X 


X 


X 


mm 


1$. 


Press  [Shi f t-F9 ] 
then  [S] 
when  finished. 


Figure  G.2.  Availability  Screen 


Schedul Inf  Screen  Menu 


The  main  scheduling  screen  menu  is  activated  by  pressing 
the  [Shift]  and  [F9]  keys  simul taneously  followed  by  the  [Z] 


key.  The  mtnu  appears  at  the  top  of  the  spreadsheet  (Figure 
0.3).  The  scheduler  uses  the  right  and  left  arrow  keys  to  move 
the  cursor  from  SCHEDULE  to  INPUTS,  TIME  LINE,  etc.  When  the 
cursor  rests  on  one  of  these  options,  a  brief  outline  of  what 
that  option  does  appears  on  the  line  below.  For  example, 
SCHEDULING  will  take  you  either  to  Tomorrow’s,  Current,  or 
Other  schedule.  When  the  user  wants  to  schedule,  he  presses 
the  (Enter]  key  or  the  [S]  key.  This  takes  the  user  to  the 
next  subset  of  menus  (Figure  0.4).  The  EXIT  option  takes  the 
user  out  of  the  DSS . 


SCHEDULE  INPUTS  TIME  LINE  COURSE  CHANGES  EXIT 
Tomorrow' s  Current  (Today's)  Other  Quit 


WI!,PW§S,,,IMii,lfo;6  IT-S7* 


I  iff iiiiiiiiiiiiiiiisiiilll 

0700  El  B-C/B 

COMMENTS  _  _  COMMENTS 


0700  El  T-N 


0715  B 1  OSC 


0755  El  B-A 


0800  El  T-W 


1015  B1  OSC 


1100  El  T-N/B 


1300  El 


1315  E1B-C/N 


1400  B1  OSC 


Figure  0.3.  Main  Scheduling  Screen 
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Figure  0.4  depicts  the  DSS  menu  hierarchy.  Until  the  sys¬ 
tem  is  fully  developed,  the  only  options  available  at  this  time 
are  those  with  connecting  arrows .  Since  the  created  schedules 
contain  the  same  macro  functions,  they  act  alike.  Thus,  TOMOR¬ 
ROW  and  the  CURRENT  SCHEDULES  both  perform  the  same  functions 
of  STUDS  AVAIL,  INSTS  AVAIL,  etc.  In  turn,  STUDS  AVAIL  and  IN- 
STS  AVAIL  both  ADD,  DELETE,  MOVE,  or  QUIT. 


Figure  0.4.  Actual  Main  Menu  Hierarchy 

SCflfiDULIMQ 

The  scheduling  menus  are  active  only  in  the  flight  shell 


portion  of  the  spreadsheet  and  not  in  the  additional  duty  or 
deconf 1 iction  areas .  The  placement  of  personnel  is  as  follows: 


To  start  scheduling,  the  user  has  only  to: 


1.  Press  [Shift-F9],  then  [Z]  to  bring  up  the 
menu. 

2.  Position  cursor  over  SCHEDULE  using  right  or 
left  arrow  keys. 

3.  Press  [Enter]  to  get  to  the  next  menu. 

4.  Position  cursor  over  TOMORROW  or  CURRENT 
using  right  or  left  arrow  keys. 

3.  Press  [Enter]  to  get  to  the  next  menu. 

-  or  - 

1.  Press  [Shift-F9],  then  [Z]  to  bring  up  the 
menu. 

2.  Press  [S]  (Schedule)  then  [T]  (Tomorrow)  or 
[C]  (Current) . 


In  addition  to  the  schedule  shell  in  Figure  0.3,  the 


[PgDn]  key  takes  the  user  to  the  additional  duty  screen  (Figure 


0.5).  The  [PgUp]  key  returns  him  to  the  flight  shell 


SIM  TIME  STUD  INSTR 


ACADEMICS 

CLASS  INSTR  START  END 


OPS  SUP  STUD  TIME  INSTR 


TOP  THREE 


SOF  AM 
P 


Figure  0.5.  Additional  Duty  Screen 


Filling  in.  the  Schedule 

When  the  user  wants  to  fill  in  the  schedule,  he  selects 
from  a  list  of  STUDentS  AVAILable  or  INSTructorS  AVAILable. 

Each  category  has  ADD,  DELETE,  and  MOVE  options.  Figure  0.6 
shows  the  screen  after  the  user  selects  SCHEDULE/TOMORROW/STUDS 
AVAIL/ADD  (or  [Shift-F9],  [A],  [A]>.  A  list  of  available  stu¬ 
dents  appears  at  the  right  of  the  screen.  Using  the  up/down 
arrow  keys,  the  user  positions  the  cursor  over  the  desired  name 
and  presses  the  [Enter]  key.  The  program  prompts  him  to  posi¬ 
tion  the  cursor  over  the  desired  space  and  press  the  [Enter] 
key.  The  program  fills  in  the  flight  time  on  the  deconf 1 iction 
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Figure  G.6.  Student  Add  Screen 


spreadsheet  (Figure  0.7)  and  then  places  the  name  in  the  se¬ 
lected  flight  position.  If  there  is  a  conflict,  the  program 
will  not  enter  the  name  on  the  shell.  The  DELETE  function 


works  in  reverse.  The  user  presses  [Shift-F9],  [A],  then  [Dl. 
He  then  places  the  cursor  over  the  name  he  wants  removed  from 
the  shell  and  presses  the  [Enter]  key.  The  name  is  removed 
from  the  shell  and  the  flight  from  the  deconf 1 iction  sheet. 

The  MOVE  function  activates  when  the  user  presses  [Shift-F9], 
[A],  then  [M] .  The  program  uses  the  delete  and  add  functions 
to  reposition  the  crew  name  in  addition  to  revising  the 
deconf 1 iction  board.  The  program  automatically  provides 
prompts  to  the  user  in  case  he  forgets  what  to  do.  The  QUIT 
option  moves  the  user  to  select  between  STUDS  and  INSTS  AVAIL. 
In  summary,  the  sequences  of  keys  to  press  to  fill  the  next 
day’s  schedule  are: 

If  in  the  next  day’s  schedule: 


To  start  scheduling  students: 


[Shi f  t-F9 ]  [2] 

[S  ] 

[T] 

[S] 

Add  Student 

[Shi f  t-F9 ]  [Z]  C  S ] 

[T] 

[S] 

[A] 

Delete  Student 

[ Shi f  t-F9 ]  [Z]  CS] 

CT  ] 

[S] 

[D] 

Move  Student 

[ Shi f  t-F9 ]  [Z]  [S] 

CT  ] 

[S] 

CM] 

or 

Add  Student 

[ Shi f  t-F9  ]  [A]  [A 

] 

Delete  Student  [Shift-F9]  [A]  CD] 
Move  Student  [Shift-F9]  [A]  [M] 

To  start  scheduling 

instructors : 

[ Shi f  t-F9 ]  [ZJ 

CS  ] 

CT] 

Cl  ] 

Add  Instructor 

[Shi f  t-F9  ]  [Z]  [S] 

CT] 

[I] 

[A] 

Delete  Instructor 

[ Shi f  t-F9 ]  [ Z]  [S] 

CT] 

[I] 

[D] 

Move  Instructor 

[Shi f  t-F9 ]  [Z]  [S] 

CT] 

Cl] 

CM] 

(3-8 


Add  Instructor 
Delete  Instructor 
Move  Instructor 


Sheet 


[Shi f  t-F9 ]  [A]  [A] 
[Shi f  t-F9 ]  [A]  [D] 
[Shi  f  t-F9 ]  [A]  [Ml 


The  deconf 1 iction  sheet  allows  the  user  to  visually  decon¬ 
flict  flight  information.  The  user  may  call  up  the  screen  by 
pressing  the  [Tab]  key.  He  may  move  within  the  sheet  using  the 
arrow  keys.  To  return  to  the  main  shell,  the  user  must  press 
the  [Home]  key. 

Figure  0.7  depicts  the  deconf 1 iction  sheet.  Takeoff  times 
are  indicated  by  the  *|*  symbol  (e.g.,  ALLAG  has  an  0830  take¬ 
off)  with  time  included  for  90  minute  brief,  30  minute  flight, 
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F********  I  = 

DANIJ 

fsaaiiiaa  13333333x33^ 

DAWSV 

Fxiiixasi  mimiiiiixF 

DEAUC 

F33II3333 | 3«I33I33333p 

DOELJ 

. . .  |  =  =  3B3Sa31«  =  33sF 

DOMAM 
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FRAHG 

FREDJ 

F3*****3* 1 3II333333I3p 

FREIJ 
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FUSSJ 

Fssaixsaa  . . 

GABLG 

Faiaaain  33333333333^ 

GROSR 

JT^f-azzasat  1  saazassaassp 

HELTC 

F33333333  I  3313S133SS3F 

HUFFD 

Pstaaaasa  sssssaassssp 

HUNSD 

paiszaas:  aasssssssssp 

Figure  G.7.  Deconf 1 iction  Screen 


and  60  minute  debrief. 


The  increments  are  accurate  to  the 


nearest  ten-minute  interval.  If  the  user  wants  to  add  informa¬ 
tion  other  than  flights,  he  may  type  the  information  in  on  the 
applicable  line.  The  program  searches  the  time  block  for  char¬ 
acters  and  does  not  enter  the  name  on  the  shell  if  a  conflict 
exists . 


Shell  Inputs 

As  the  program  is  constructed  presently,  it  reads  data 
from  a  file  called  434EDIT . ASC .  This  file  is  the  edited  ASCII 
version  of  the  wing  lines  disk.  The  file  (Figure  G.B)  has  all 
the  commas  removed  so  the  program  may  read  the  data  properly. 
The  data  must  be  in  this  form  and  named  434EDIT. ASC  f or  the 
program  to  accept  the  data.  With  this  format  complete,  the 
user  may  create  the  shell. 
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Figure  Q.8.  Wing  Lines  Input  Data  File  ( 434EDIT . ASC ) 


a  Haa  Shell 


Once  the  proper  434EDIT.ASC  file  has  been  created  (see 
previous  section) ,  the  user  may  select  the  flight  shell  input 
portion  of  the  menu.  He  presses  the  [Shift-F9]  and  [Z]  keys  to 
invoke  the  main  menu  and  selects  INPUTS  followed  by  FLT  SHELL. 


The  proper  key  sequence  is: 

[ Shi f  t-F9  )  [2]  [I]  [F] 

The  wing  lines  input  prompt  is  displayed  (Figure  G.9)  with  in¬ 
structions  on  what  to  do  next.  After  the  user  presses  the 
[Enter]  key,  the  data  is  transformed  and  written  to  a  new  file. 


Place  the  Wing  Disk 
containing  Flight  Shell 
Lines  into  the  A  drive 
of  the  Z-248.  Press 
ENTER  when  ready. 


Figure  09.  Wing  Lines  Input  Prompt 


The  system  now  prompts  the  user  to  name  the  file  (Figure  0.10) 
The  file  name  is  the  date  for  which  the  data  is  to  be  used.  ] 
other  words,  if  the  data  is  for  the  third  day  of  April,  the 
file  name  will  be  3APR 


0-  1  1 


*'  *  w  r  w.  w  w. 


NOTE:  You  must  save  this  created  shell  under  the  date  of 

it’s  use  with  the  date  format  DMMM  or  DDMMM 
(e.g.  ,  3 JAN  or  28FEB) . 

Enter  the  date  of  the  new  schedule: 


Figure  0.10.  Shell  Creation  Prompt 


SAVlng  Work 


It  is  advisable  to  periodically  save  the  spreadsheet  while 

scheduling.  This  prevents  loss  of  information  due  to  operator, 

program,  or  system  errors.  There  are  several  methods  by  which 

to  save  the  schedule: 

Press  [F10]  [SI  [A]  [Inter]  [R]  or 
Press  [/]  [S]  [A]  [Enter]  [R]  or 
Press  [Alt-FlO]  [Enter]  [R] 


IX  IX  Dotan  ’  t  Work 


The  program  is  designed  to  handle  most  error  situations 
If  for  some  reason  the  program  halts  or  refuses  to  go  any  far¬ 
ther,  it  is  not  advisable  for  the  user  to  take  it  out  on  the 
computer.  Follow  these  steps. 

1.  STOP' 

2.  Write  down  what  happened  that  led  up  to  the 
malfunction  (i.e..  which  keys  were  pressed) 

3.  Quit  the  program  -  the  macros  write  to  man y 

areas  of  the  spreadsheets  and  files  so 

saving  these  errors  may  destroy  future 
access  to  the  schedule 
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Prof raM  Coda  and 


The  author*  uaad  tha  ENABLE  Macro  language  in  tha  fol 


lowing  coda  Modification  of  Flight  Schadular  (FS)  requires 


a  thorough  undarittnding  of  ENABLE  capabilitiaa  Tha  exple 


nation*  of  tha  coda  in  this  appendix  will  b*  adequate  to 


understand  how  FS  work* 


MACROS 


•  0  MCM 

This  i*  tha  AUTOEXEC  startup  Macro 


Bypass  ENABLE  startup  Menu 


(End) 


rail  AVA I  Lab  1 1 1 ty  spreadsheet  up 


usrAVAIL  3SF 

i F2 ) ks  l  ' 


Invoke  F  (credits  aanu 


(  F  1  0  ) 

F 


Pause  2  seconds  before  continuing 


2 X  >  ( Pause ) 


Enter  data  to  bypass  credits  Menu 


.  END  of  SO  MCM 


. .  S 1  MCM 

. .  This  is  the  continuation  of 
the  «Urt-up  Hero,  00.  MCM, 

.  invoked  by  P.MMU. 

Invoke  systea  date  conversion 
.  in  AVAIL. S8P 

(  '  P») 

y 

.  Edit  date  retrieval  aacro . 
(P0> 

woaara2 

Erase  aacro  screen . 

(P®> 

(Del  ) 

(End) 

(OX)  ’ 

( Hoae  > 

Write  new  date  aacro 

uer  (  Mom  ) 

(Down) 

.  .  Copy  nest  day's  date  in 


( AP9) 

1  (  Down  > 

< Down ) 

SEP  <  Down ) 

<4X) (Left) 

.  .  Copy  (BTM)  to  end  of  aac: 

( APS ) 

1  (  2X ) (Down) 


Save  date  retreival  aacro. 

(AP10) 

a(P10) 

qy 


Betrelve  toaorrow's 
schedule  to  window  *2  . 


4 

V. 

>$ 
t  4 

.* 

(FO) 
wo (&F0) 

2  (FO) 

"U 

•7 

*  » 

* 

•a 

;  ;  Invoke  DHIF/TDY  menu. 

(F2)kzl~ 

( “F10) 

•i 

d 

f  * 

;  BHD  of  *1 .MCM 

& 

;;  M2 . MCM 

«r‘l 

;  ;  This  ucro  is  modified  to 

* 

; ;  reflect  the  current  dete 

•‘J 

uer  1  ODBC . SSF~ 

;;  43.  MCM 

;  This  macro  la  a  blend  designed 

*  J 
. 

;  to  reserve  Window  *3  for  future 

; ;  copy/ input  operations 

1, 

;  HMD  of  e3.MCM 

*« 

S 

f. 

;  *4 . MCM 

;  This  macro  reads  ASCII  data  from 

,<l 

,< 

file  434EDIT.ASC  and  transfers  it 

V 

• 

;  to  ZATEMP  spreadsheet  via  a 
;;  database  file  434. DBF. 

»  * 

;;  Save  file  and  go  to  main  menu. 

,'J 

(F0> 

s (Home) 

a* 

1 

ry 

— - 

• , 

;;  Close  window  and  select  ZVEWSCH.SSF. 

tV 

(FO) 

»;j 
*  < 

»;• 

* 

-*1 

.•i'1 

weymf a (End) 

;;  Copy  ZNEWSCH.SSF  to  ZATEMP. SSF. 

•  • 

»  9 

,  ' 

•4' 

■ 

> 

H-3 

'tm 


rt  Vs  v*V) 

'O'*  \  • 


vOf 

.f  V 


y  v1,  **  \\  v  v  *r  v 


”n-T7  ,*■ 


YVVV. 


c  (2X>  ~ 

ZATEMP . SSF~ 
y (Esc) 

•  » 

;;  Copy  ASCII  fila  434EDIT . ASC 
;;  to  databasa  file  434. DBF. 

udi 0434. ABF" 

f a434EDIT . ASC (2X) (Down) 

u434.CTF~ 

{IF©) 

c~ 

(Esc) 

;;  Craata  fiald  nanaa  for  434. DBF. 

; ;  d434.DBF~ 

(PgDn) 

mm 

{ 2X> (Down) 

LINE, ZEBO , ONE , TAKEOFFT I M , L ANDT I ME , ABE AT I ME 1 , 
ABEATIME2 , CONFIG , ABEA , TYPEBIDE~ 

*  • 

;;  Opan  window  containing  ZATEMP. SSF. 

{&Homa} 

uar ZATEMP . SSF" 

a  I 

;;  Copy  data  from  434. DBF  starting 
;;  at  ZATEMP. SSF  call  afOO. 

/d {Up) 

{F7) 

(50X) {Down} 

{F7  } 

(&F9) 

mm 

oaf 00~ 

9  9 

;;  Go  to  ZATEMP . SSF  call  bl  and 
;;  copy  formula  thru  call  bOl. 

/modHFlO) 

q(Homa) 

(Bight) 

/  wc~ 

b2 . .  bCl~ 

I  9 

;;  Shift  ZATEMP. SSF  data  in 
; ;  an-  and  ao-columna  ona 
;;  column  to  tha  right. 


H-4 


/wmsnOO.  .*0120" 
soOO(2X)~ 

i  » 

;;  Center- J uati fy  lo-column  data. 
»  » 

/wracsoOO. .so!20~ 


Copy  configuration  substring 
conversion  formula  to  csll 
snS9  and  invoks  sprsadshsst 
f -macro  to  convert  load 
configurations  and  ersata 
scheduling  flight  shell. 


(F2) sn59~ 

•substr (smSO . 1 . 1 ) & ( *  1  * ) ~ 
/ wesnSO { 2X) ~ 
snOO . . snl20~ 

<  !F9> 
f 


;;  Copy  additional  duty  shell 
;;  below  flight  shell. 

/wcedl . . eu20~ 
a21<2X)~ 

»  » 

;;  Invoke  Q.MMU  to  query  user 
;  to  name  the  new  ZATKMP .  S8P 
;;  scheduling  shell. 

(*F10) 

I 

;  END  of  S4.MCM 


;;  S9.MCM 

;  This  is  the  continuation  of 
;;  the  start-up  macro,  SO . MCM  A 
;;  SI. MCM.  Invoked  by  D.MWU. 

V  9 

;;  Transfer  personnel  availability 
list  to  schedule  in  window  • 2 . 

(F2)lal~ 

(FO) 

w2g/ccwl lal . . mx59~ 
lal" 

9  9 

;;  Copy  Available  instructors 


H-5 


to  coll  t2  in  window  *2 . 

ire) 

ab4 . . abS9~ 

t2 ( 2X) “ 

(Hom) 

*  > 

;;  Activate  achedullng  Min  aonu. 
(  '  FO) 


BUD  o t  AS . MCM 


THK  FOLLOWI MO  IS  FROM  AVAIL.  SSF 


LBTTBB  OF  X’S  AMD  QUALIFICATIONS 

IP  MX 


MAMS 

BAMK 

CP 

FLT 

CAT 

EXP 

UIPIP 

UIPBD 

FLTLD 

BDIP 

RBI  P 

ALLAO 

• 

MAJ 

IP 

B 

A 

K 

X 

X 

X 

AMDKC 

MAJ 

IW 

C 

M 

X 

BBCKO 

• 

LTC 

IP 

A 

A 

B 

X 

X 

X 

X 

BBCKJ 

• 

CPT 

IP 

B 

B 

X 

X 

X 

X 

BKCXW 

• 

CPT 

IP 

A 

A 

X 

X 

X 

X 

BOHAM 

• 

CPT 

IP 

C 

B 

X 

X 

X 

X 

CASBX 

• 

MAJ 

IP 

A 

A 

X 

X 

X 

X 

X 

X 

DAMIJ 

• 

CPT 

IP 

C 

A 

X 

X 

X 

X 

DAWBV 

MAJ 

IP 

B 

C 

M 

X 

DKAUC 

• 

CPT 

IP 

A 

A 

X 

X 

X 

X 

DOKLJ 

• 

CPT 

IP 

C 

A 

X 

X 

X 

X 

DOMAM 

CPT 

IP 

A 

C 

N 

FBAMO 

• 

LTC 

IP 

D 

A 

X 

X 

X 

X 

F1XDJ 

• 

CPT 

IP 

C 

B 

X 

X 

X 

X 

FBXIJ 

COL 

IP 

D 

B 

X 

T 

X 

FU88J 

• 

MAJ 

IP 

B 

A 

X 

X 

X 

X 

OABLO 

• 

CPT 

IP 

C 

A 

X 

X 

X 

X 

H-S 


AVAILABILITY 

DNIF  LEAVE  TDY  OTHER  AVAIL 

0 


AVAIL  COLUMN 
FORMULA 


•COUNT (MW4. 
•COUNT  (MM  . 
•COUNT  (MM. 
•COUNT ( MW7 . 
•COUNT (MW6 . 
•COUNT  (MM. 
•COUNT (MW 10 
•COUNT (MW 1 1 
•COUNT (MW12 
•COUNT (MW 1 3 
•COUNT (MW 14 
•COUNT (MW 13 
•COUNT (MW 1C 
•COUNT (MW17 
•COUNT (MW 18 
•COUNT (MW19 
•COUNT ( MW20 


Makaa  eoluani  of  ONIF,  TDY,  A  LEAVE  paopla 


MZ4) 
ICS) 
ICC) 
MZ7 ) 
MZ8) 
ICO) 

. MZ10) 
.MZU) 
.  1C  1 2 ) 
.  MZ 1 3 ) 
.  MZ  1 4  ) 
.  MZ  1  3 ) 
. MZ10) 
.  MZ  17 ) 
.  1C  18) 
.MZ19) 
.  MZ20  > 


-Datarmlna  Rad  Dot  IPa 


/xcnf 4‘ 


/wtc(F2)  la9~/wra  .  (4x)  (Right)  (PgDn) 


-Eraaa  old  DNIF/TDY/LEAVE  liat 


■Maka  ranga  nama  DNIF  in  call  laO 


/wrncDNIF”~ (Right) 


■Maka  ranga  nama  TDY  in  call  IcO 


/wrncTDY~~ (Right) 


Maka  ranga  nama  OTHER  In  call  ldO 


/wrncOTHEB' 


■Go  to  call  na3  (Availability) 


V  1 


(F2)na3 


Go  down  *  coll 


(Down) 


■Call  that  call  AVAIL 


/wrncAVAIL* 


If  and  of  Hat,  call  D.MNU  and  and 


/ x 1 (AVAIL-8) ~(F2) k*l~(‘F 10) d/xq 


If  AVAIL-0,  go  to  call  nj 1 1 


/xi ( AVAIL< 1) **/xgn) 11 


-Go  to  aarkad  call  In  row-call  It  TEST 


(End) (Laf  t) /wrncTEST' 


-Go  to  column  haadlng-call  it  CAUSE 


( 3x ) (PgUp) ( 2x ) (Down) /wrncCAUSB' 


If  CAUSE  ia  DNIF ,  go  to  call  nj21 


/xi (CAUSE- ’DNIF* ) ~/xgnJ21 


If  CAUSE  la  LEAVE,  go  to  call  nj27 


/xi (CAUSE- ’LEAVE* ) ~/xgnJ27‘ 


If  CAUSE  la  TDYF ,  go  to  call  nj33 


/xi (CAUSE- *TDY’ ) ~/xgnj33* 


If  CAUSE  la  OTHER,  go  to  call  nj38 


/xl  (CAUSE-  "OTHER*  )  **/xgnJ38* 


■Go  to  call  cal  lad  TEST 


(F2)TEST‘ 


■Find  naaa-call  It  D 


(22x) (Laf t) /wrncD* 


■Go  to  call  balow  DNIF-call  it  DNIF 


(F2)DMIF~ (Down) /wrncDNIF' 


V 


a 


-Copy  name  called  D  to  DNIF  cell 


(F8) D~DNIF' 


-Go  to  cell  called  TEST 


(F2)TEST' 


-Go  back  to  availability  column 


(End) (Right)/xgnj 1 1“ 


-Go  to  cell  called  TEST 


(F2JTEST' 


-Find  name-call  it  L 


( 23x)  (Lef t)/wrncL~~ 


-Goto  cell  below  LEAVE-call  it  LEAVE 


(F2)  LEAVE'*’  (Down)  /wrncLEAVE' 


-Copy  name  called  L  to  LEAVE  cell 


(F8)L~LEAVE' 


■Go  to  cell  called  TEST 


{ F2  >  TEST' 


-Go  back  to  availability  column 


(End) (Right) /xgnj 1 1' 


-Go  to  cell  called  TEST 


(F2)TEST* 


-Find  name-call  it  T 


(24x) (Lef t) /wrncT' 


■Go  to  cell  below  TDY-call  it  TDY 


{ F2 ) TDY" ( Down ) / wrncTDY' 


-Copy  name  called  T  to  TDY  cell 


<F8)T~TDY* 


Go  to  cell  called  TEST 


(F2)TEST~ 

- Go  back  to  availability  column 

(End) (Right) /xgnj 11" 

- Qo  to  cell  called  TEST 

(F2)TEST" 

- Find  name-call  it  0 

(25x) (Lef t) /wrncO"" 

- Goto  cell  below  OTHER-call  it  OTHER 

( F2 ) OTHER" { Down ) /wrncOTHER~ ~ 

- Copy  name  called  0  to  OTHER  cell 

(F8)0"0THER~ 

- - - (j0  to  cell  called  TEST 

(F2JTEST" 


Go  back  to  availability  column 


(Right) /xgn J 11" 


(\Y) 

Converts  date  to  * UAH'  format. 


Write 


(F2)no49~0~ 


. . . . . If 

/xi ( #M0D ( #TOD A Y , 7 ) <>6)"/xgno8 


(F2) no43~#T0DAY*2 


today  isn’t  Sat, 


Go  to  cell  no43 


0  in  cell  no40 


go  to  cell  no8 


write  formula 


H-  10 


■Go  down  a  call  -  writ*  formula 


{ Down) ©TODAY*  3~/xg no  17' 


■If  today  Isn’t  Fri ,  go  to  call  noil 


/xi (©MOD (•TODAY ,7)<>5)~/xgnoll‘ 


-Go  to  call  no43  -  writa  formula 


{F2 ) no43~©T0DAY 


■Go  down  a  call  -  writa  formula 


(Down)©T0DAY+3“/xgno 17' 


•If  today  isn’t  Sun,  go  to  call  nol4 


/xi  ( ©MOD  ( ©TODAY  ,7)  <  >  0 )  "VxgnolA' 


-Go  to  call  no43  -  writa  formula 


(F2) no43~©TODAY* 1 


■Down  a  call-writa  formula-Go  nol7 


(Down)©T0DAY*2*'/xgnol7* 


■Go  to  call  no43  -  writa  formula 


(F2) no43~#T0DAY 


■Down  a  call-writa  formula-Goto  no  T 


( Down ) ©TOD AY ♦  l~/xgno!7' 


^-Writa  1  in  call  no48 


{F2)no48~r 


If  1  than  writa  JAN  in  call  no43 


/xi  (©M0NTH(no43)  «  1 )  "  ( F2 )  no43“ JAN' 


■If  2  than  writa  FEB  in  call  no43 


/xi (©MONTH (no43) «2>  ~ (F2) no43”FEB* 


/xi (©MONTH (no43) *3) ~ < F2 } no45“MAR* 


If  3  than  writa  MAR  in  call  no45 


H-ll 


P  ■  ’ 


- If  4  than  writ*  APR  in  c*ll  no45 

/xi ( •MONTH ( no4  3 ) * 4 >  ~ ( F2 ) no 4 5 ~ APR" 

- If  5  than  writ*  MAY  in  c*ll  no45 

/xl ( •MOUTH (no43) «3) ~  < F2 ) no45~MAY~ 

- If  o  then  writ*  J  UN  in  c* 1 1  no43 

/xl (•MONTH ( no43 ) «fl> ~ (F2 ) no43~ JUN~ 

- If  7  th*n  writ*  JUL  in  c*.l  nc4? 

/xi  ( •MONTH  (  no4  3  )  ~  (F2  >  no43~  JUL~ 

- If  g  then  writ*  AUO  in  c*»l  nc4? 

/xi ( •MONTH ( no43 ) -8) * ( F2 ) no 43 ~ AUO' 

- ... - If  q  then  writ*  SIP  in  c*  1  I  nc>4? 

xi i  •MONTH ( no4  3> «9>'(F2)no43'SEP~ 

-  - - - If  jo  th*n  writ*  OCT  in  c*  i  i  no4? 

xl ( •MONTH <no43> • 1 1 > ' ( F2 1 no43 'OCT~ 

. - . If  11  then  writ*  NOV  in  c*ii  no4? 

xi ( •MONTH t no43 ; -IP' < F2 > no43 ' NOV' 

. ----  -  - If  ’j  then  wr  it*  DEC  in  c  *  .  .  n  o  4 

xi > •MONTH i no43> ' i 2 ' ~ i F2 ) no43'DIC' 


xl ; no49* 1 > '  x jno37 


(  F2 ) no48 “ 


If  cell  no49*  1  go  to  c*l.  no3' 


3o  to  c*ll  no40 


- - - If  two  digit*  in  day,  go  to  no34 

/xl  ( •LEN  < •STR I  NO  <  ®DAY ( no  4  3 )  )  ) -2) ~/xgno34~ 

- KPrit*  d*y  ♦  month  (5MAR1 


•SUBSTR ( •STRING ( *DA Y ( no4  3 )  >.1.1) Ano45~ 


■Go  to  c*ll  no35 


x  g  n o  3? ' 


•SUBSTR  »  #STR I MQ ( •DAY lno43)  >  . 1 . 2) Ano45‘ 


Writ*  day  ♦  month  (10MAR) 


■Oo  to  c*ll  no44-copy  to  c*ll  no43 


F2  >  no4  4~  wc  ~  < (Up  ) 


■Go  to  cell  nol6 


xgno  18' 


■Go  to  cell  no47 


<  F  2  ’  n  o  4  ‘ 


If  two  digits  in  day,  go  to  no41 


xi  i •LEN (•STRING <*DAY (no43)  ) ) =2) ~/xgno4  1' 


•SUBSTR  (  •STRING  ( CD  AY  ( no43 )  )  ,  1  ,  l)Ano45' 


■Writ*  day  ♦  month  (5MAR) 


x  gno4  2 ' 


-Go  to  cell  no42 


•Write  day  ♦  month  (10MAR) 


•SUBSTR  ( •STRING  ( #DAY  ( no43 )  )  ,  1 ,2)8cno45' 


■Go  up  one  cell  -  quit  macro 


{ Up ) /xq 


■••Today’s  System  Date 


•TODAY 


■••Next  Day’s  System  Date 


•TODAY* 1 


■••System  Month 


H-  13 


$ 


MICROCOPT  RESOLUTION  TEST  CHART 
BUWAU  Of  STW0ARDS-1963-A 


*ftTod*y'a  Schedule  Date 


15DEC 


10DEC 


**Next  Day’ 8  Schedule  Date 


«*Carriage  Return 


**Test  Flag 


(NT) 

Process  DNIF  status  change 


ZATEMP . SSF 

{  \A) 

This  macro  brings  up 
Scheduling  menu  (A,D,M,Q) 

asaiassasaasaasssaaisasas 

/xi (ra49* *S  * ) ~/xmra85~/xq 
/xmrg65~/xq 


H-  14 


(MESS  1 ) 


{ \B}  IPS 

Searchs  for  taksoff  time  and  fills  in  deoonf 1 iction 
and  select  an  IP  Name  and  put  in  on  the  schedule 


aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 


board 


- Instruct  User . to  position  cursor 

(F8)MESSl~a20~~(?)/wrea20~~ 

- Message  One 

USE  ARROW  KEYS  OR  MOUSE  TO  POSITION 
CURSOR  WHERE  IP  IS  DESIRED  (THEN  ENTER) 

- Names  Cell  START  and  Moves  Up  a  Cell 

/wrncSTART~~(up) 

- Names  cell  TOTIME 

/wrn cTOTIME 

- If  length  of  TOTIME  is  8  then  move  the  pointer  up  &  loop 

/xi ( •LEN ( TOT I ME ) «5) ~ (Up) /xgrelO 

- - Check  first  alphanumeric,  if  letter  move  two  left 

/xi (•ALPHA (OSUBSTR (TOTIME , 1 , 1 ) ) ) «l~<2x) (Left) /wrncTOTIME'"' 

- Position  the  screen  to  open  the  window 

(F2)cl~(10x) (Right) 

- Open  Window  and  Display  IP  Names,  Pause  for  input 

/mtsv (Home) (F6) /mtsu(Down) { ? ) /wrncNAME~~ 

- Search  a  list  of  takeoff  times 

/xckal" 

- Indicate  the  range  that  would  be  filled 


/wrncBEQIN". (llx) (Right) 


- Check  to  see  if  there  is  already  some  event  scheduled 

/xi (•COUNT (BEGIN) >0)~/xgre22 

- If  no  conflict  exists,  copy  the  name  to  the  shell 

/wcNAME" START" 

- Go  to  the  deconf liction  sheet  and  fill  in  a  flight 

(F2)BEGIN"F* (Right)** (Right)** (Right) 

**(Right)*| (Right) ** (Right) 

** (Right )** (Right)** (Right)** (Right }*F" 

- Close  the  small  window  and  redisplay  the  shell 

/mtsc(Home) (F2) START" 


/xq 


The  end 


(\C)  Students 

Searchs  for  takeoff  time  and  fills  in  deconf liction  schedule 
and  select  a  student  name  and  put  in  on  the  schedule 


aaaasasatasssasas: 


- Names  cell  start  and  moves  up  a  cell 

/wrncSTART"" (up) 

- Names  cell  totime 

/wrncTOTIME — 

- If  length  of  totime  *  5  move  the  pointer  up  and  loop 

/xi (#LEN (TOTIME) *5) " (Up) /xgrn4 

- Check  first  alphanumer ic ,  if  letter  move  two  left 

/xi (#ALPHA(#SUBSTR (TOTIME, 1 , 1) ) ) *l"(2x) (Lef t) /wrncTOTIME"" 
- Position  the  screen  to  open  the  window 


(F2)bgl~{ 17x) (Right) 


Open  window  ,  display  IP  Karnes ,  pausa  for  usar  input 


/mt*v{Homa) (F6) /mtsu(Down) { ? } /wrneNAME"" 

- Saarch  totimas  &  find  amount  to  mova  right 

/xckal" 

- indicata  ranga  that  is  fillad  if  fliar  is  assignad 

/wrneBEGIN" . { 1  lx} {Right}" 

- Chack  if  thara  is  a  conflict 

/xi <#COUNT (BEGIN) >0)~/xgrnl7 

- No  conflict  axists,  copy  tha  name  to  tha  shall 

/we NAME" START" 

- Go  to  daconf 1 iction  shaat  and  fill  in  a  flight 

(F2) BEGIN~F« (Right) *« (Right) »* {Bight >»* {Right) 

■ | (Right) ■* (Right) »» {Right) *■ (Bight) 

** (Right) -■ (Bight) -F~ 

— - - -Closa  tha  small- window  and  radisplay  tha  shall 

/mtac(Homa) (F2) START" 

- Tha  and 

/xq 

(\D) 

Saarchs  for  takaoff  tima,  dalatas  nama  from  main  schadula 
and  dalatas  tima  slot  from  tha  daconf 1 iction  shaat. 

- Hamas  call  NA  and  movas  up  a  call 

/wrncNA~~{up) 

- Hamas  call  TOTIME 

/wrncTOTIME~~ 


H-  17 


J.  '( 


- If  totime  *  5  then  move  the  pointer  up  end  loop 

/xi (#len (TOT I ME) *5) ~ (up) /xgrd28 

- Check  first,  alphanumeric,  if  letter  move  two  left 

/xi ( • ALPHA ( •SUBSTR ( TOT I ME , 1 , 1) ) ) =l~<2x) {Lef t) /wrncTOTIME" 


■Searches  for  the  name  in  NA  and  send  cursor  to  it 


/xckbl' 


-Qives  the  found  name  the  range  name  ‘NAME* 


/wrncNAME' 


■Searches  for  a  totime  and  moves  right 


/xckal' 


■Erase  the  range  indicated 


/wre . { 1  lx) {Eight)" 


■Qo  to  starting  place  and  put  in 


(Home) (F2)NA~ 


-The  end 


/xq 


(\E) 

Searchs  for  totime,  deletes  name  from 
slot  from  the  deconf 1 iction  board 


main  schedule  and  time 


/wrncNAT" (up) 


/wrncTOTI ME~~ 

- - - If 


Names  cell'  NA  and  moves  up  a  cell 


Names  cell  totime 


TOTIME  length  is  5  move  pointer  up  and  loop 


/xi (•len(TOTIME)«5)~(up)/xgre40 


- Check  first  alphanumer ic ,  if  a  letter  move  two  left 

/xi (•ALPHA (•SUBSTH (TOTIME , 1 , 1) ) ) *l~(2x) (Lef t) /wrncTOTIME~~ 
- Searches  for  name  in  NA  and  send  cursor  to  it 


/xckcl" 


Name  the  name  NAME 


/ wrncNAME~~ 


/xckal~ 


Searches  for  a  totime  and  moves  right 


Erase  the  range  indicated 


/wre . { 1 lx) { Right)" 


Go  to  starting  place  and  put  in  ‘ 


(Home) {F2)NA~ 


/xq 


The  end 


(\F) 

This  macro  forms  the  basic 
shell  using  2hrs  30min  turn  times. 


Go  to  so  121  and  write  900,  go  to  soOO 


(F2)sol21~099~(F2)eo00~ 


- Name  ZA  and  if  cell  below  equals  zero,  go  to  ral3 

/wrncZA~ . (Down)~/xi (•COUNT (ZA) -0) ~/xgral3~ 

- Center  cell  contents 


(F4) (Down) /xgral 1~ 


I 

I 

|  /wcsnflO. .sol20~c2~~ 


- Copy  information  starting  in  c2 

(Home) (Right) (Down) 
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Movs  ths  first  lins  into  row  1 


/m.  (2x)  (Right) ~ {Up} ~ (Up) 

- Name  tha  first  lins  GOT I ME 

/wrncGOTIME~~ 

- - - - - Mams  ths  first  taksoff  tims  FTO 

{Up} / wrncFTO~~ {Down} 

- Writs  in  ths  blank  spacss 

_ {Right}  {Right} _ {2x} {Lsf t} {Down} 

- - - Nams  ths  nsxt  csll  XA 

/wrncXA — 

- - - If  XA  s  qua  Is  FTO  thsn  go  to  ral7 

/xi (XA-FTO) ~/xgral7~ 

- If  XA  is  lass  than  FTO  thsn  go  to  ra27 

/xi (XA<FTO)~/xgra27~ 

- If  tims  bstwssn  flights  >  2.5  hours  go  to  ra25 

/xi ( (GOTIMB+23 1 ) >XA) ~/xgra25" 

- Move  ths  column  of  taksoff  timss  to  ths  right 

/wm. {3X} (PgDn) {2x} {Right} ~ 

- Move  six  to  ths  right  and  down 

(End) {Up} (End) {Up} {6x} {Right} {Down}~ 

- - - Movs  six  to  ths  right  and  down 

(End) (Up} (End) (Up) {Ox} (Right) (Down) /xgral4~ 

- If  XA  is  grsatsr  than  FTO  thsn  movs  down 

/xi (XA> FTO) ~{ Down) 

- Movs  ths  column  of  taksoff  timss  down 


/wm. (3x) (PgDn) {2x} (Right) ~ (Down)  "VxgralO~ 


Eras*  any  extra  takeoff  times  and  quit 


/wre. (3x) (PgDn) (2x) (Right) ~ (Home) /xq 


(\G) 

Moves  an  instructor  name  from  one  slot  to  another 


sxssKSBXKssasssassssxsxscsKxsatsssxassasxsssssxsaBss 


- Prompts  user  to  position  cursor  over  the  IP  to  move 

(F8)MESS2~a20~~(?)/wrea20~~ 


names  cell  na  and  moves  up  a  cell 


/wrncNA~~ (up) 

- names  cell  totime 

/wrn cTOTIME — 

--if  length  of  totime  is  S  then  move  the  pointer  up  and  loop 
/xi (•len (TOTIME) *S) ~ (up) /xgsf 1 1 

- check  first  alphanumeric ,  if  letter  move  two  left 

/xi (#ALPHA (SSUBSTR (TOTIME , 1 , 1) ) ) «l~(2x) (Lef t) /wrncTOTIME~~ 


- position  the  screen  to  open  the  window 

(F2)cl~(10x) (Right) 

- open  the  window  and  display  the  IP  Names 

/mtsv(Home) (FO/mtsu 

- searches  for  name  in  ‘NA*  in  instructor  list 

/xckbl~ 

- remember  it  by  calling  it  ‘name* 

/ wrncNAME — 


searches  for  totime  and  moves  right 


/xckal" 


erase  the  range  indicated 


/wre. {llx} {Right}" 

- Prompt*  user  to  position  cursor  where  the  IP  is  to  go 

{F8}MESS3~a20~~{F6} (?) {F9> {Del}ba20~~ 

- names  cell  start  and  moves  up  a  cell 

/wrncSTART"" {up} 

- names  cell  totime 

/wrn cTOTIME — 

- if  length  of  totime  is  5  move  pointer  up  and  loop 

/xi (•LEN {TOTIME) *5) ~ {Up} /xgsf 22 

- check  first  alphanumeric,  if  letter  move  two  left 

/xi { • ALPHA ( OSUBSTR ( TOT I ME , 1 , 1) ) ) »l~{2x} {Left} /wrncTOTIME"" 

- go  to  NAME  and  move  the  appropriate  amount  right 

{FO} (F2}NAME~/xckal~ 

- --indicate  range  that  would  be  filled 

/wrncBEGIN". {llx} {Right}" 

- check  if  there’s  some  conflict 

/xi (•COUNT ( BEGIN) >0) "/xgsf 33 

- no  conflict  exists,  move  the  ips  name  to  'START* 


{F2 } START"/ wcNA~~ {F2 } NA~ _ ~ 

- go  to  the  deconf liction  sheet  and  fill  in  a  flight 

{F2)BEGIN~F* {Right} --{Right}** {Right} 

--{Right}*) {Right} -- (Right} 

»« (Right} -- {Right}-* {Right} 

*» {Right} »F~ 
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close  the  little  window  and  go  to  (Home) 


(F6> (F9 } wx {Home } 


/xq 


the  end 


•  SUB* 

(\X)  This  macro  returns  to  instructor  availability  menu. 

ss==i3t2=;ti===z=3r==:::=3a==S2==z::2t===z:r:=:=;==i=z= 

(F9) wx(Home) (F2) j 9~/xmra50~ 


{\Z> 

This  forms  the  user  input  menu. 


/xmra50~/xq 


SCHEDULE 

/xmra55~ 

INPUTS 
/xmrj 5S~ 

TIME  LINE 
/xmrtS5~ 

COURSE 

/xmra50 

CHANGES 

*** 

EXIT 

/xmrh50 

TOMORROW 

/xmra0O~ 

CURRENT 
/xi ( ra49= 
/xi (ra49“ 

0) ~/xmra0O 
l)~(F9)w2g 

OTHER 

/xmra56~ 

QUIT 

/xmra50~ 

STUDS  AVAIL 
/wrncPATH — (F2>  ra49~S~ 
(Horae) (F2>PATH~/xmra05 


INSTRUCTORS  AVAIL 
/wrncPATH~~(F2>ra49~I~ 
(Home) {F2}PATH~/xrarg05 


PRINT  KEEP 

/xrara0O~  (F9)se~r/xmra0O~ 


QUIT 

/xmra55~ 


Student 

ADD 

( ! F9)c/xq 


DELETE 
{ ! F9)e/xq 


MOVE 

/xmra05~ 


QUIT 

/xmra0O~ 


NO  YES 

/xrara50~  (&F9)q/xq 

STUDENT  INSTRUCTOR  FLIGHT  SHELL  SIMULATOR 
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/xmr  j  55~  (AF9)5/xq  (*F10)a/xq 


/xmr j  55 


ACADEMIC  DUTIES /MEETINGS 

/xmrj55~  /xmrj55~ 


Instructor 

ADD  DELETE  MOVE  QUIT 

(!F9)b/xq  {!F9)d/xq  Zxmra65~  /xmra60~ 


COMPARISON  MACROS 

ssaasaxaxxaxasaaaa 

KA  --  SEARCHES  FOR  A  TAKEOFF  TIME  AND  THE  APPROPIATE 
AMOUNT  TO  MOVE  RIGHT 

KB  --  SEARCHES  FOR  AN  INSTRUCTOR  NAME  AND  SENDS  THE 
CURSOR  TO  IT  IN  THE  DECONFLICT I ON  SCHEDULE 
KC  --  SEARCHES  FOR  A  STUDENT  NAME  AND  SENDS  THE  CURSOR 
TO  IT  IN  THE  DECONFLICT I ON  SCHEDULE 


KA 

SEARCHES  FOR  A  TAKEOFF  TIME  AND  THE  APPROPIATE  AMOUNT 
TO  MOVE  RIGHT 

aaaaaaaaaaxaaxaxaaxaaaaaaxaaaxaaaxaxaaxaxxaaxaaxaxxxxxxxxx 


/xiT0TIME*500~(2x) (Right)/xr 
/xiT0TIME*C05~(2x) (Right) /xr 
/xiTOTIME*0 10~ (2x) (Right)/xr 
/xiT0TIME*015~(2x) (Right)/xr 
/xiT0TIME=020~(2x) (Right)/xr 
/xiTOTIME=»625~(2x)  (Right)/xr 
/xiTOTIME»630~(2x) (Right)/xr 
/xiTOTIME*535~(2x) (Right)/xr 
/xiT0TIME*040~ (2x> (Right)/xr 
/xiTOTIME*545~(3x) (Right) /xr 
/xiT0TIME=050~(3x) (Right)/xr 
/xiTOTIME~655~(3x) (Right)/xr 
/xiTOTIME*700~(3x) (Right)/xr 
/xiT0TIME*705~(4x) (Right)/xr 
/xiT0TIME*7 10~ { 4x) (Right)/xr 
/xiT0TIME*715~ (4x) (Right)/xr 
/xiT0TIME«720~(4x) (Right)/xr 
/xiT0TIME*725~(5x) (Right) /xr 
/xiTOTIME=730~(5x) (Right)/xr 
/xiTOTIME*735~(5x) (Right)/xr 
/xiT0TIME»740~(5x) (Right)/xr 
/xiT0TIME»745~(6x) (Right) /xr 
/xiT0TIME*750~(6x) (Right}/xr 
/xiTOTIME*755~ (6x) (Right)/xr 
/xiTOTIME*800~(5x) (Right)Zxr 
/xiT0TIME*805~(7x) (Right)Zxr 


/xiTOTIME* 1 230~ ( 20x) {Right}/xr 
/xiTOTIME® 1235~{20x} {Right}/xr 
/xiTOTIME* 1240~ {2 Ox) {Right}/xr 
/xiTOTIME® 1245~(21x> {Right} /xr 
/xiTOTIME® 1250~{21x) (Right)/xr 
/xiTOTIME* 1255~{21x} {Right}/xr 
/xiTOTIME® 1300~{21x) {Right>/xr 
/xiTOTIME* 1 305~ { 22x) {Right)/xr 
/xiTOTIME® 13 10~ (22x) {Right>/xr 
/xiTOTIME* 13 15~{22x) {Right} /xr 
/xiTOTIME® 1320" { 22x} {Right}/xr 
/xiTOTIME* 1325~ {23x} {Right}/xr 
/xiTOTIME* 1330~ { 23x} {Right}/xr 
/xiTOTIME® 1335" { 23x} {Right}/xr 
/xiTOTIME* 1340~{23x} {Right} /xr 
/xiTOTIME® 1345~{24x} {Right}/xr 
/xiTOTIME® 1350~{24x} {Right} /xr 
/xiTOTIME® 1355~ {24x} {Right}/xr 
/xiTOTIME* 1400~ { 24x} {Right}/xr 
/xiTOTIME® 1405~{25x} {Right}/xr 
/xiTOTIME® 1410~{25x} {Right}/xr 
/xiTOTIME® 1415~{25x} {Right}/xr 
/xiTOTIME® 1420~{25x} {Right}/xr 
/xiTOTIME® 1 425~ { 26x} {Right}/xr 
/xiTOTIME* 1 430~ { 26x} {Right}/xr 
/xiTOTIME* 1 435~ { 20x} {Right}/xr 
/xiTOTIME® 1440~ { 26x} {Right}/xr 
/xiTOTIME* 14457 {27x} {Right}/xr 
/xiTOTIME* 1450~ {27x} {Right}/xr 
/xiTOTIME* 1455~{27x} {Right}/xr 
/xiTOTIME® 1500~{27x} {Right}/xr 
/xiTOTIME® 1 505" { 28x} {Right}/xr 
/xiTOTIME* 1510~{28x} {Right}/xr 
/xiTOTIME* 15 15~{28x} {Right} /xr 
/xiTOTIME* 1520~{28x} {Right} /xr 
/xiTOTIME* 1 525~ { 29x} {Right}/xr 
/xiTOTIME* 1530~{29x} {Right}/xr 
/xiTOTIME* 1535~ { 29x} {Right}/xr 
/xiTOTIME* 1540~{29x} {Right}/xr 
/xiTOTIME* 1545~ {30x} {Right}/xr 
/xiTOTIME* 1 550~ {30x} {Right}/xr 
/xiTOTIME* 1555~ {30x} {Right)/xr 
/xiTOTIME* 1000~{30x} {Right}/xr 
/xiTOTIME* 1605~{31x} {Right}/xr 
/xiTOTIME* 10 10~ {3  lx} {Right} /xr 
/xiTOTIME* 1815~(31x} {Right}/xr 
/xiTOTIME* 102O~ {3  lx} {Right} /xr 
/xiTOTIME* 1825" {32x} {Right}/xr 
/xr 
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XB 


SEARCHES  FOR  AH  INSTRUCTOR  NAME  AND  SENDS  THE  CURSOR  TO 
IT  IN  THE  DECONFLICTION  SCHEDULE 

333323338333333233333333333353332333X3333333333333333=333333 


/xina*a2~ {F2)a2~/xr 
/xina»a3~{F2)a3~/xr 
/xina«a4~{F2>a4~/xr 
/xina*a5~{F2>a5~/xr 
/xina*afl~ {F2}86~/xr 
/xina=a7~(F2)a7~/xr 
/xina*a8~{F2)a8~/xr 
/xina=*a9~{F2)  a9~/xr 
/xina=alO~{F2)alO~/xr 
/xina=a ll~{F2)sll~/xr 
/xina=al2~{F2)al2~/xr 
|  /xina»al3~{F2}al3~/xr 

/xina»al4~{F2)al4~/xr 
/xina«al5~{F2}alS~/xr 
/xina*al«~{F2)al8~/xr 
/xina*a 17~ (F2) a 17~/xr 
/xina*al8~{F2)aI8~/xr 
/xina*a 19~ (F2) a 19~/xr 
/xina«a20~(F2)a20~/xr 
/xina»a21~ (F2) a2 l~/xr 
/xina*a22~{F2)a22~/xp 
/xina«a23~<F2)a23~/xr 
I  /xina*a24~{F2}a24~/xr 

}  /xina»a25~(F2)a25~/xr 

/xina=a28~{F2)a28~/xr 
/xina*a27~ (F2)a27~/xr 
/xina=a28~{F2)a28~/xr 
/xina*a29~(F2)a29~/xr 
/xina»a30~{F2)a30~/xr 
/xina»a31~ {F2)a31~/xr 
/xina*a32~ (F2)a32~/xr 
/xina»a33~(F2)a33~/xr 
/xina*a34~{F2}a34~/xr 
/xina*a35~{F2)a35~/xr 
/xina*a3fl~ {F2} a36~/xr 
/xina«a37~{F2}a37~/xr 
/xina»a38~{F2) s38~/xr 
/xlna«a39~{F2)a39~/xr 
/xina*a40~<F2)a40~/xr 
/xina*a41~{F2)a41~/xr 
/xina»a42~{F2)a42~/xr 
|  /xina«a43~<F2>a43~/xr 

/xina»a44~(F2)a44~/xr 
\  /xina«a45~(F2)a45~/xr 

;  /xina«a48~{F2)a46~/xr 

/xina»a47~{F2}a47~/xr 
I  /xina*a48~{F2)a48~/xr 
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/xina*a49~(F2)a49~/xr 
/xina«a30~{F2>a50~/xr 
/xina=a51~{F2)a51~/xr 
/xina*a32~ (F2) a52~/xr 
/xina»a53~(F2)a33~/xr 
/xina*a54~{F2)aS4 ~/xr 
/xina*a35~{F2)a35~/xr 
/xina»a53~{F2)a56~/xp 
/xina»a57~{F2>a57~/xr 
/xina=aS8~{F2>a58~/xr 
/xina*a39~ {F2)a59“/xr 
/xina*a60~ (F2)a60~/xr 


KC 

SEARCHES  FOR  A  STUDENT  NAME  AND  SENDS  THE  CURSOR  TO  IT 
IN  THE  DECONFLICT ION  SCHEDULE 

3«SS2l33tS8SllSSSSS3IS8l*2a:S33SSS3S33t838«S312Sr:sSS233a:3 


/xina*bx2~{F2)bx2~/xr 

/xina*bx3~(F2)bx3~/xr 

/xina»bx4~(F2)bx4~/xr 

/xina*bx5~{F2)bx3~/xr 

/xina*bx6~{F2)bxO~/xr 

/xina«bx7~ (F2) bx7~/xr 

/xina*bx8~{F2)bx8~/xr 

/xina*bx9~ (F2) bx9~/xr 

/xina»bxlO~(F2)bxlO~/xr 

/xina*bxl l~(F2)bxI l~/xr 

/xina»bxl2~{F2)bxl2~/xr 

/xina*bxl3~{F2)bxl3~/xr 

/xina*bxl4~{F2)bxl4~/xr 

/xina*bxl5~ (F2)bxlS~/xr 

/xina*bxlfl~{F2)bxl6~/xr 

/xina*bxl7~{F2)bxl7~/xr 

/xina«bxl8~{F2)bxl8~/xr 

/xina»bx!9~(F2)bxl9~/xp 

/xina«bx20~ (F2)bx20~/xr 

/xina*bx21~(F2)bx21~/xr 

/xina*bx22~ (F2)bx22~/xr 

/xina»bx23~(F2)bx23~/xr 

/xina»bx24~(F2)bx24~/xr 

/xina«bx23~{F2)bx23~/xr 

/xina-bx20~<F2)bx23~/xr 

/xina»bx27~{F2)bx27~/xr 

/xina«bx28~ (F2)bx28~/xr 

/xina«bx29~ (F2)bx29~/xr 

/xina«bx30~(F2)bx30~/xr 

/xina«bx31~{F2}bx31~/xr 

/xina«bx32~{F2)bx32~/xr 

/xina-bx33~(F2}bx33~/xr 

/xina»bx34~ (F2) bx34~/xr 
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/xina»bx35~ (F2}bx35~/xr 
/xina*bx38~ (F2) bx36~/xr 
/xina=bx37~ (F2)bx37~/xr 
/xina*bx38~(F2)bx38~/xr 
/xinaabx39~ (F2)bx39~/xr 
/xina«bx40~(F2}bx40~/xr 
/xina*bx41~(F2)bx41“/xr 
/xina»bx42~(F2)bx42~/xr 
/xina»bx43~(F2)bx43~/xr 
/xina*bx44~ {F2)bx44“/xr 
/xina»bx45~{F2)bx45~/xr 
/xina*bx46~ (F2) bx46~/xr 
/xina=bx47~{F2)bx47~/xr 
/xina*bx48~(F2)bx48~/xr 
/xina*bx49~(F2)bx49~/xr 
/xina=bx50~ (F2)bx50~/xr 
/xina«bx51~{F2)bx51~/xr 
/xina*bx52~{F2}bx52~/xr 
/xina»bx33~{F2)bx33~/xr 
/xina»bx34~(F2)bx34~/xr 
/xina*bx55~{F2}bxS5~/xr 
/xina-bx56~{F2)bx5e~/xr 
/xina*bxS7~ (F2)bx57~/xr 
/xina»bx38~{F2}bx58~/xr 
/xina*bx39~ (F2)bx59~/xr 
/xina*bx60“ (F2)bx80~/xr 


EMBEDDED  FORMULA’S 

CONVERTS  THE  WING  DATA  INTO  THE  PROPER  FORMAT 


(0830) 


•int (SI  59/60) #100+ (•mod (SI59 , 60) ) 
•*nt (SI60/60) #100+ (•modCSieO ,60) ) 
•int (SI6 1/60) #100+ (•mod (SI 6 1 , 60) ) 
•int (SI02/6O) #100+ (•mod (SI62 , 60) ) 
•int (SI 63/60) #100+ (•mod (SI 63 , 60) ) 
•int (SI64/60) #100+ (•mod (SI84 , 60) ) 
•int (SI63/60) *100+ (•mod (SI63 , 60) ) 
•int (SI66/60) #100+ (•mod (SI66 ,60) ) 
•int (SI67/60) #100+ (•mod (SI67 , 60) ) 
•int (SI 68/60) « 100+ (•mod (S 168 ,60) ) 
•int (SI69/60) #100+ (•mod (SI69, 60) ) 
•int(SI70/60) #100+ (•mod (SI70 , 60) ) 
•int (SI71/60) » 100+ (•mod (SI71 , 60) ) 
•int  (SI72/60)  #100+  (*1006(3172,60) ) 
•int (SI73/60) #100+ (tood (SI73 , 60) ) 
•int(SI74/60)»100+ (•mod ( SI 74 , 60) ) 
•  int(SI73/60)»i00+ (•mod (SI73 ,60)  ) 
•int(SI76/60) #100+ (•mod (SI76 , 60) ) 
•int(SI77/60)»100+ (•mod (SI77 , 60) ) 
•int (SI78/60) » 100+ (•mod (SI78.60) ) 
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APPENDIX  I 


HQQXBQQK 

The  hookbook  is  an  extension  of  a  daily  diary  incorpo¬ 
rating  both  ideas  for  future  applications  and  future  work 
required  to  evolve  the  DSS.  The  authors  recommend  the  for¬ 
mat  shown  below.  It  must  contain  four  essential  elements. 


Date:  3  CATEGORY :  T/n£  L/AUT 

IDEA:  7 ht  0Sf  jJ  kt  f%  fctff 

frock  taeJk  tack  sfudetct  is 

9/1 '  Firikir,  the  s+mlmtf 

?/  CalUJ  +c  kt  ftct  fit 

schedule  f  fht  shtk tJ  ht  tlirfUycJ 

Atxf  fa  fits  *+mf. 

CIRCUMSTANCE:  pick  *  dt**  mu/f  ACCSAy- 

Ipsh  *  certain  number  oT  tv*hfS  7a  m 

order. 


(20) 

Figure  1.1.  Notecard  Example 


The  elements  of  the  hookbook  necessary  to  document  the 
idea  evolution  process  are: 

1.  Date  of  the  idea. 

2.  Category  of  the  idea. 

3.  Idea. 

4.  Circumstance (s)  under  which  the  idea  came  about. 


The  date  and  category  help  the  developer  or  user  classify 
the  various  thoughts.  This  classif ication  may  help  direct 


future  research/modification  efforts  or  areas  of  emphasis. 
The  idea  itself  is  important,  but  so  is  the  circumstances 
under  which  the  idea  evolved.  This  situation  brings  about 
an  understanding  of  the  environment  out  of  which  the  user 
documented  his  concept. 


i 

[  25  Aug  80  PRIORITY 


Idea:  Be  able  to  sort  by  student  priority.  These  prior¬ 

ities  would  include  scheduling  by  student  continuity,  such 
as  the  case  where  a  student (s)  falls  behind  his  training 
schedule  due  to  weather  or  maintenance.  Thus,  the  student 
farthest  behind  would  be  scheduled  first.  Ciroumatanea : 

TDY  to  Holloman  AFB  confirmed  the  user  need  -  our  experience 
in  scheduling  taught  us  this  feature  was  necessary. 


31  Aug  86  PRIORITY 


Idea:  A  parallel  thought  would  schedule  an  entire  class  by 

continuity  in  the  same  manner  as  an  individual  student. 
a l T»fMin»t fcannB :  Our  experience  in  scheduling  taught  us  this 
feature  was  necessary.  Not  only  must  the  scheduler  monitor 
a  specific  student,  questions  from  management  are  about  the 
status  of  a  particular  class. 


31  Aug  80  PRIORITY 


Idea:  In  addition,  be  able  to  schedule  each  student  with 

their  assigned  instructor (s) .  This  prioritized  matching 
would  assign  a  student's  primary  instructor  first,  followed 
by  his  secondary  instructor,  flight  commander,  operations 
officer,  or  any  other  qualified  instructor  (as  a  last  re¬ 
sort)  .  ctreuiMtane* ;  Our  experience  in  scheduling  taught 
us  this  feature  was  necessary.  Safety-of-f light  consider¬ 
ations  always  influenced  the  need  for  an  instructor  to  fly 
with  a  particular  student,  whenever  possible,  for  better 
rapport  and  instructional  technique. 
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2  Sep  86 


AVAILABILITY 


Idee:  Incorporate  the  ability  to  sort  by  availability 

(i.e.,  there  is  always  some  personnel  missing  for  Leave,  TDY 
or  DNIF)  and  bring  up  a  list  of  only  available  IPs  and  Stu¬ 
dents  to  select  from  when  scheduling.  The  procedure  cur¬ 
rently  used  is  selecting  from  a  list  of  all  of  the  IPs  and 
Students  in  the  squadron.  ?  Our  experience  in 

scheduling  taught  us  this  feature  was  necessary.  Often, 
personnel  were  TDY  or  on  leave  and  the  schedulers  were  not 
informed  as  to  the  status  change.  Supervisors  who  knew  of 
the  orders  usually  told  the  schedulers  the  change  of  status 
as  they  were  reviewing  the  schedule  for  errors  (right  before 
the  schedule  was  due  to  Wing) . 


2  Sep  86 


QUALIFICATIONS 


Idea :  Same  as  above,  except  for  sorting  by  qualifications. 

For  example,  some  students  are  specially  monitored  (i.e., 
put  on  Red  Dot  status).  Red  Dot  students  can  only  fly  with 
Red  Dot  qualified  IPs.  The  DSS  should  be  able  to  flag  the 
user  about  a  mismatched  Red  Dot  student/instructor  relation¬ 
ship.  ;  Our  experience  in  scheduling  taught  us 

this  feature  was  necessary.  The  instructor/student  matchup 
depends  on  the  qualifications  of  the  IPs  and  the  character¬ 
istics  of  the  student. 


4  Sep  86 


DECONFLICT I ON 


Idea:  The  DSS  should  be  able  to  deconflict  each  squadron 

member’s  individual  schedule.  As  the  squadron  scheduler 
constructs  tomorrow's  schedule,  he  fills  out  a  separate  De- 
confliction  Board.  Perhaps  deconflict  graphically  by  making 
a  timeline  across  the  top  of  the  screen  and,  as  the  squadron 
scheduler  schedules  each  event,  the  DSS  would  display 
XXXXXXXXXX’s  under  that  time  block  for  that  indi-vidual. 

:  One  of  the  most  difficult  tasks  in  scheduling 

was  relying  on  the  deconf 1 iction  board  during  an  end-of-day 
crisis.  In  most  cases  it  was  kept  up-to-date.  The  times 
the  boards  were  not  current  were  the  times  sorties  and 
training  events  were  not  accomplished  due  to  scheduling  a 
person  for  different  events  at  the  same  time. 


8  Sap  86 


TIME  LINE 


Idea :  The  DSS  should  be  able  to  keep  track  of  which  event 

each  student  is  currently  on.  Moreover,  when  the  student's 
name  is  called  upon  to  be  put  into  the  schedule,  the  event 
that  specific  student  is  on  should  be  displayed  next  to  his 
name.  Cipeuniit.*ne« :  Each  student  must  accomplish  a  certain 
number  of  events  in  a  certain  order.  Squadrons  do  not  have 
the  luxury  of  extra  flights,  simulators,  or  make-up  classes 
due  to  scheduling  errors  while  tracking  a  student’s  events. 


8  Sep  86 


PREREQUISITES 


Idea :  The  OSS  should  be  able  to  check  for  completion  of 

prerequisites  for  each  and  every  event.  Cipmimiitanee :  The 
syllabus  is  kept  near  the  scheduling  grease  board  and  is 
consulted  for  completion  of  prerequisites  prior  to  sched-ul- 
ing  a  student  for  a  ride.  A  student  must  accomplish  certain 
prerequisites  for  each  event  so  that  flight  safety  is  not 
compromised  (e.g.,  the  student  flies  a  low-altitude  mission 
without  having  had  the  proper  academic  training) . 


18  Sep  86 


SYSTEM 


Idea :  Use  a  database  to  store,  manipulate , and  sort  infor¬ 

mation  for  use  in  a  spreadsheet  schedule.  ciroijm*t*ng« : 
Through  literature  search  and  interviews  with  experts  on 
various  software,  we  discovered  the  flexibility  of  a  spread¬ 
sheet  combined  with  the  sorting/manipulating  power  of  a 
database  is  an  ideal  solution  to  a  scheduling  DSS  problem. 


27  Sep  86  FLIGHT  SHELL 


Idea:  Copy  the  Wing-supplied  Flight  Shell  into  a  Database 

ntrgiiiiat.>np» :  Ltc  Kunzman  at  Holloman  AFB  mentioned  he  was 

working  on  a  program  to  convert  the  raw  data,  currently  in 
an  unusable  mixed-format  form  supplied  by  Wing,  for  use  on 
the  Z-100  computer. 
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13  Oct  80 


REPRESENTATION 


Id**:  Deaign  *  MAIN  MENU  that  will  repreaent  graphically 

all  of  our  acraana.  Th*  uaar  ahould  b*  abl*  to  aalact  any 
acraan  from  any  poaition  within  tha  hiararchy.  And  aalact 
tha  MAIN  MENU  from  any  acraan,  for  inatanca,  uaa  tha  func¬ 
tion  kay  P2  to  bring  up  tha  MAIN  MENU  in  any  application. 
Parhapa  hava  tha  MM  ahow  up  in  a  window  to  tha  aida  of  tha 
currant  acraan  ao  a a  to  hida  a a  littla  information  aa  poaa- 
ibla.  gixauaalAIIfiA -  Storyboard  avaluation  ganaratad  tha 
idaa  baaad  upon  tha  ROMC  mamory  aid  raquiramant  plua  tha 
uaar'a  naadad  ability  to  amploy  varioua  portiona  of  tha  DSS 
at  will. 


I 

» 

\ 

I  20  Oct  80  CONTROL 


Idaa:  Ba  abla  to  raprogram  function  kaya  (PI , • • . ,F10)  to 

giva  tha  uaar  and  programaiar  graatar  flaxibility.  Circum- 
atanca :  Storyboard  daaign  of  ROMC  control  of  diffarant 

function*  dapandad  upon  programming  tha  function  kaya.  A 
DOS  window  to  an  axtarnal  aaaambly  languaga  program  ia  tha 
only  mathod  to  accompliah  radafining  function  kaya  known 
(bayond  knowladga  acopa)  to  tha  author*  at  thia  tima. 


23  Oct  88 


MEMORY  AIDS 


Idaa:  On-lino  Halp  ahould  ba  available  in  any  acraan.  Cir- 

pniMtaTif :  Tha  naad  to  incorporate  a  Halp  function  atammad 

from  our  own  quaationa  about  aoftwara  and,  moat  certainly,  a 
now  uaar’a  initial  quaationa  about  a  program  that  would  ba 
written. 
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20  Oct  80 


MEMORY  AIDS 


Idea ;  Informational  prompts  would  be  nice.  Circumstance : 
Natural  curiosity  about  what  a  program  is  doing  and  what  the 
user  should  do  next  arose  from  our  own  experience  in  working 
with  and  evaluating  various  software  for  use  in  the  DSS. 


4  Nov  86  SYSTEM 


Idea:  Tomorrow's  schedule  and  Today’s  schedule  will  be  in¬ 

put  forms  to  a  data  base.  Sorting  and  categorizing  will  be 
accomplished  and  displayed  to  a  user  via  a  report  form. 
Circumstance :  Discovery  that  ENABLE  is  very  limited  in  it’s 

ability  to  interface  a  database  quickly  and  simply  with  a 
spreadsheet  schedule. 


10  Nov  86 


CONTROL 


Idea:  Make  the  DSS  much  more  user  friendly  by  enabling  the 

user  to  use  mouse  to  select  commands  and  move  around  the 
screen.  Qi  ppnm«t.jnp» ;  Our  experience  in  using  menu-driven, 
mouse-actuated  software  in  spreadsheet  application  software 
convinced  us  as  to  the  ease,  practicality,  and  versatility 
of  a  mouse,  especially  to  a  new  user. 


14  Nov  86  SYSTEM 


Idea :  Create  the  entire  scheduling  program  in  a  spreadsheet 

application.  Circumet.ance :  Discovery  that  ENABLE  database, 
while  very  powerful  in  the  data  sorting  and  manipulating 
process ,  could  not  support  a  dynamic  input  form  necessary 
for  scheduling.  Sorting,  while  slower  in  spreadsheet,  takes 
about  the  same  time  as  a  database  by  the  time  the  spread- 
sheet/database  interface  takes  place.  In  addition,  coding 
within  a  spreadsheet  is  much  simpler  and  far  more  flexible 
than  from  within  a  database. 


20  Nov  86 


SYSTEM 


Idea :  Make  a  mouse  menu  to  allow  use  with  ENABLE.  Circum¬ 

stance  :  Discovery  that  a  LOTUS  SYMPHONY  menu  loaded  into 
ENABLE  allowed  the  mouse  to  function,  although  not  all  the 
menu  functions  worked  in  ENABLE. 


23  Nov  86  EVALUATION 


Idea:  Use  ’SIDEKICK*  for  an  evaluation  tool.  In  each  ap¬ 

plication  of  our  DSS  have  a  'SIDEKICK*  file  that  tracks  user 
comments  on  the  DSS  performance.  The  usual  evaluation  cri¬ 
teria  should  be  used: 

a.  Ease  of  in-put. 

Help  calls. 

Mistakes. 

‘b.  Changes  in  decision. 

c.  Service. 

Time  on  the  system. 

•  of  iterations. 

d.  Productivity. 

Time/motion  study. 

-  Delphi  method. 

f!<  rniiiMtAng* :  A  method  needs  to  be  found  to  document  user 
comments  for  feedback  analysis  and  design  evolution.  Side- 
ick  does  work  within  ENABLE,  yet  it  redefines  the  [TAB]  key 
function  and,  in  certain  cases,  inhibits  macro  operation. 


30  Nov  86 


DECONFL I CT I ON 


Idea:  The  DSS  should  be  able  to  track  ‘CREW  REST*.  Crew 

rest  is  a  12  hour  period  that  must  be  observed  from  the  end 
of  an  individuals  last  event  to  the  first  event  of  the  next 
day.  The  DSS  should  be  able  to  inform  the  user  if  ‘CREW 
REST*  is  violated.  c<  :  Flying  regulations  re- 

uire  a  certain  period  of  rest  between  flying  activities. 
Working  the  deconf 1 ict ion  problem  with  the  spreadsheet  re¬ 
minded  us  of  this  fact. 


2  Dec  86 


MEMORY  AID 


Idea :  'Idiot-proof'  the  program.  The  DSS  should  be  able  to 

find  erroneous  inputs  and  flag  the  user.  C  ireuMtanc* : 

Past  experience  with  programs  and  ROMC  incorporation  of  mem¬ 
ory-aid  flags  define  this  requirement. 


15  Dec  86  EVALUATION 


Idea :  Use  ENABLE  word  processing  windows  to  track  user  com¬ 

ments  for  the  design  evolution  process.  C  l  rwnimtangn  ;  Dis¬ 
covery  that  Sidekick  would,  during  a  thesis  progress  demon¬ 
stration,  adversely  affect  the  advanced  programming  applica¬ 
tions  currently  residing  within  the  existing  code. 


30  Jan  87  IMPLEMENTATION 


Idea:  Create  an  INSTALL  program  to  move  the  scheduling  pro¬ 

gram  and  its  applicable  files  into  an  INSTALL-generated  di¬ 
rectory.  m  roniMt.flnf ;  Noticing,  through  installing  sev¬ 
eral  word  processing  programs ,  the  ease  by  which  the  pro¬ 
grams  were  set  up  requiring  a  minimum  of  user  interaction. 


1  Feb  87 


IMPLEMENTATION 


Idea:  Create  a  batch  file  to  enter  ENABLE,  find  out  the 

name  of  the  next  day's  schedule,  exit  ENABLE,  test  to  see  if 
the  files  exist,  then  re-enter  ENABLE  and  prompt  the  user  to 
create  the  scheduling  spreadsheet  file.  Circumstance : 
Presently,  the  program  crashes  (stops)  if  the  next  day’s 
schedule  is  not  present  when  called  by  the  DSS. 


APPENDIX  J 


Evaluation  must  be  a  continuing  process.  DSS  evalua¬ 
tion  should  begin  before  the  technical  phases  (analysis,  de¬ 
sign,  development,  testing,  and  installation)  and  continue 
beyond  the  life  of  the  DSS.  If  evaluation  is  done  at  the 
end  of  the  life  of  the  DSS,  it  -is  likely  not  to  be  done  at 
all,  and  if  done  it  is  likely  to  be  a  ‘confirmation’  rather 
than  a  useful  source  of  information  (18:158). 

What  to  Measure .  Figure  J.l  shows  the  measures  that 
can  be  used  to  evaluate  the  impact  of  the  scheduling  DSS. 

The  measures  are  divided  into  four  categories  (18:59). 

1.  Productivity  measures  are  used  to  evaluate  the  im¬ 
pact  of  the  DSS  on  decisions. 

2.  Process  measures  are  used  to  evaluate  the  impact 
of  the  DSS  on  decision  making. 

3.  Perception  measures  are  used  to  evaluate  the  im¬ 
pact  of  the  DSS  on  decision  makers. 

4.  Product  measures  are  used  to  evaluate  the  techni¬ 
cal  merit  of  the  DSS. 

How  la  Measure .  The  evaluation  will  be  described  in 
terms  of  two  systems:  (1)  an  initiation  system  (the  DSS) 


PRODUCTIVITY  MEASURES 

Time  to  reach  a  decision 

Cost  of  making  a  decision 

Results  of  the  decision 

Cost  of  implementing  the  decision 

PROCESS  MEASURES 

Number  of  alternatives  examined 
Number  of  analyses  done 

Number  of  participants  in  the  decision  making 
Time  horizon  of  the  decision 
Amount  of  data  used 

Time  spent  in  each  phase  of  decision  making 
Time  lines  of  the  decision 

PERCEPTION  MEASURES 

Control  of  the  decision-making  process 
Usefulness  of  the  DSS 
Ease  of  use 

Understanding  the  problem 
Ease  of  'selling*  the  decision 
Conviction  that  the  decision  is  correct 

PRODUCT  MEASURES 

Response  time 
Avai labi 1 i ty 
Mean  time  to  failure 
Development  costs 
Operation  costs 
Maintenance  costs 
Education  costs 


(18:160) 


Figure  J.l.  Measures  for  DSS  Evaluation 


whose  impact  is  to  be  evaluated,  and  (2)  a  target  system 
(the  decision,  the  organization,  the  product)  on  which  im¬ 
pact  is  to  be  measured.  Each  evaluation  will  describe  the 
expected  impact  of  an  initiating  system  on  a  target  system 
(  18 : 159)  . 


The  initiating  and  target  systems  can  be  all  or  parts 
of  four  basic  systems  shown  below  in  Figure  J.2. 


(Sprague : 28) 

Figure  J.2  The  Decision-Making  System 


Initiating  and  target  systems,  for  evaluation,  can  be  vari¬ 
ous  inter  and  intra  combinations  of  elements  of  the  four  ba¬ 
sic  systems.  The  initiating  system  will  usually  be  all  or 
specific  party  of  the  DSS. 

Although  the  decision  support  system  is  treated  as  a 
black  box  in  Figure  J.2,  it  it  important  to  recall  that  the 
overall  system  is  the  decision-making  system.  The  decision¬ 
making  system  consists  of  a  manager/user  who  uses  a  decision 
support  system  to  confront  a  task  in  an  organizational  envi¬ 
ronment  . 


Five  methods  are  selected  for  use  to  measure  and  evalu¬ 
ate  the  impact  of  the  scheduling  DSS.  These  methods  do  not 
represent  the  only  possible  evaluation  schemes  but  they  do 
cover  a  wide  range  from  quantitative  to  opinion  oriented 
methods.  The  following  paragraphs  briefly  describe  each 
method,  list  its  apparent  advantages  and  disadvantages,  and 
present  examples  of  its  use  (18:161). 

Event  Logging .  In  an  event  logging  evaluation,  events 
that  might  indicate  OSS  impact  are  recorded.  An  example  is 
keeping  a  log  of  customer  complaints  before  and  after  imple¬ 
mentation  of  a  customer  service  DSS.  Event  logging  is  the 
least  structured  of  the  methods  to  be  discussed,  and  it  has 
the  least  well  defined  set  of  techniques.  The  methodology 
for  event  logging  is  a  combination  of  historiography  and 
journalism.  The  basic  technique  is  the  recording  of  events 
that  relate  to  the  effects  being  investigated.  The  events 
may  be  actions,  opinions,  newspaper  articles,  items  from 
memos,  dates,  and  so  on.  Judgment  is  required  in  selecting 
the  events  to  be  recorded,  and  the  set  of  possible  relevant 
events  is  not  predef inable .  The  recording  may  be  on  a  con¬ 
tinuous  or  a  before/after  basis.  The  evaluation  is  simply 
an  analysis  of  the  recorded  events. 

Event  logging  is  most  useful  when  quantitative  measures 
cannot  be  used,  when  a  time  series  of  effects  is  of  inter¬ 
est,  and  when  multiple  effects  are  being  considered.  Event 
logging  can  also  provide  valuable  insight  for  designers  and 


users  of  similar  systems,  and  can  be  a  useful  background  for 
other  evaluations.  Event  logging  has  a  wide  range  of  appli¬ 
cability,  is  relatively  simple  to  perform,  does  not  require 
special  data  collection  techniques,  and  can  be  performed  on 
a  continuing  basis.  However,  it  usually  results  in  large 
volumes  of  data  which  may  be  difficult  to  interpret,  and  it 
is  difficult  to  guarantee  the  completeness  and  accuracy  of 
the  data. 

Attitude  Survey .  The  attitude  survey  is  a  method  that 
attempts  to  measure  opinions  through  a  questionnaire  admin¬ 
istered  to  a  set  of  individuals.  The  questionnaire  may  be 
mailed  out  or  administered  via  interviews.  Questions  cover 
a  wide  variety  of  attitudes,  and  usually  provide  multiple- 
choice,  short  statement,  or  open-ended  answer  formats. 

There  is  a  large  body  of  psychological  and  behavioral  re¬ 
search  which  can  be  used  in  designing  and  analyzing  the 
questionnaires.  For  example,  question  questionnaires  have 
been  developed  for  measuring  perception  of  working  environ¬ 
ment,  motivation,  and  interpersonal  contacts.  For  best  re¬ 
sults  the  questionnaires  are  administered  at  various  inter¬ 
vals  during  the  development  and  use  of  the  DSS  and  the  re¬ 


sults  are  compared.  There  are  four  major  problems  that  may 
arise  in  attitude  surveys  (18:163). 

1.  In  developing  a  questionnaire  to  measure  atti¬ 
tudes,  one  may  be  trying  to  quantify  that  which  is 
not  quantifiable  and  the  subsequent  analysis  may 
be  misleading. 


J-5 


2.  Questionnaire  respondents  may  interpret  questions 
differently  than  intended,  and  answers  to  some 
questions  may  influence  answers  to  others.  Thus 
unintended  impacts  may  be  measured,  or  a  single 
impact  may  be  interpreted  as  more  than  one. 

3.  Administering  questionnaires  may  be  an  inconve¬ 
nience  to  individuals  and  expensive  (in  terms  of 
hours  lost  by  respondents  and  hours  spent  by  in¬ 
terviewers)  . 

4.  The  method  does  not  identify  the  causes  of  any 
measured  changes . 

Because  of  these  problems  it  is  best  to  use  questionnaires 
and  analysis  techniques  validated  by  others  or  by  pretests, 
and  if  possible,  to  facilitate  data  collection  by  sampling. 
An  attitude  survey  is  most  useful  when  the  target  system 
consists  primarily  of  people  and  when  perception  measures 
are  being  used. 

Bating  and  Weighing .  Bating  and  weighting  is  a  highly 
structured  method  for  a  composite  numerical  evaluation.  The 
methodology  involves  developing  a  set  of  parameters  related 
to  the  system  and  effects  being  evaluated,  weighting  these 
parameters  in  terms  of  relative  importance,  and  having  one 
or  more  individuals  rate  the  system  on  each  parameter.  For 
example,  department  managers  could  be  asked  to  rate  a  DSS  on 
accuracy,  timeliness,  and  usability  of  displays  using  a 
scale  of  1  to  10,  and  to  assign  a  relative  importance 
(weight)  to  each  of  the  three  factors.  The  summation  of  the 
ratings  times  the  corresponding  weights  gives  an  evaluation 


score.  The  scores  from  each  individual  may  be  averaged  or 
totaled . 


J-6 


The  rating  and  weighting  method  may  involve  several 


MUOLKUXkXHXVtif. 


evaluations  and  a  comparison,  or  a  single  evaluation.  How¬ 


ever,  because  ratings,  and  sometimes  the  weights,  are  ordi¬ 


nal  numbers  (i.e.,  they  can  be  ranked,  but  their  differences 


are  meaningless) ,  the  summation  of  ratings  times  weights  is 


undefined  theoretically.  Moreover,  in  comparing  two  scores, 


only  if  all  rating  for  one  system  are  less  than  those  for 


the  other,  and  the  same  evaluators  rate  each  system,  do  the 


scores  necessarily  give  an  indisputable  direction  of  differ¬ 


ence.  Therefore,  in  analyzing  results  of  rating  and  weight¬ 


ing,  the  evaluator  must  remember  that  the  numbers  are  not 


precise  and  may  not  accurate.  If  the  ratings  and  weights 


are  reliable,  this  method  is  the  easiest  to  interpret.  If 


not,  the  method  will  be  misleading  (18:164) 


System 


This  method  attempts  to  quantify 


effects  through  measurements  of  the  performance  of  the  tar¬ 


get  system,  and  therefore  it  is  similar  to  performance  eval¬ 


uation.  In  fact,  if  the  target  system  is  the  DSS ,  the  eval¬ 


uation  should  use  product  measures  for  the  DSS.  Measuring 


the  time  to  locate  a  suspect  before  and  after  implementation 


of  a  DSS  for  a  police  department  is  an  example  of  a  system 


measurement  evaluation.  The  measurements  may  be  collected 


automatically  by  DSS  or  other  sensors,  through  question¬ 


naires,  interviews,  or  observations,  or  extracted  from  docu¬ 


ments.  The  method  of  evaluation  is  usually  a  before/after 


comparison  of  measurements.  The  analysis  of  the  measure- 


f  t  **. 


ments  often  utilize  statistical  techniques,  the  data  collec¬ 
tion  is  straightforward  and  often  employs  sampling,  and  the 
results  are  usually  easy  to  interpret.  Unfortunately,  the 
method  has  a  narrow  range  of  applicability  because  it  re¬ 
quires  that  the  affected  elements  of  the  target  system  have 
performance  characteristics  that  can  be  quantified.  How¬ 
ever,  if  this  requirement  is  satisfied,  system  measurement 
is  the  most  reliable  evaluation  method  (18:164). 

Value  Analysis .  Peter  Keen  recently  proposed  an  evalu¬ 
ation  technique  which  he  called  value  analysis  (7:1-16). 

The  approach  is  similar  to  cost/benefit  analysis,  with  three 
important  differences.  First,  the  emphasis  is  on  benefits 
first  and  costs  second.  This  emphasis  is  based  on  the  as¬ 
sumption  that  it  is  the  benefits  that  are  of  primary  inter¬ 
est  to  decision  makers  and  that  the  calculations  of 
cost/benefit  ratios  are  not  necessary  if  the  benefits  meet 
some  threshold  and  the  costs  are  within  some  acceptable 
limit.  Second,  the  method  attempts  to  reduce  risk  by  re¬ 
quiring  prototyping  as  part  of  the  evaluation  method.  The 
assumption  here  is  that  the  prototype  is  a  low-risk,  rela¬ 
tively  inexpensive  way  to  obtain  relatively  accurate  evalua¬ 
tion  data.  Third,  the  method  evaluates  DSS  as  an  R  &  D  ef¬ 
fort  rather  than  a  capital  investment.  An  R  &  D  evaluation 
tends  to  encourage  innovation  rather  than  return  on  invest¬ 
ment  . 
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Keen  describes  value  analysis  as  a  series  of  four 


steps . 

1.  Establish  the  operational  list  of  benefits  that 
the  DSS  must  achieve  to  be  acceptable. 

2.  Establish  the  maximum  cost  that  one  is  willing  to 
pay  to  achieve  the  benefits. 

3.  Develop  a  prototype  DSS. 

4.  Assess  the  benefits  and  the  costs. 

The  advantages  of  the  value  analysis  approach  are  that 
it  it  simple  and  integrated  with  an  installation  approach 
(prototyping).  The  main  disadvantage  is  that  it  is  a  lim¬ 
ited  form  of  evaluation,  which  may  not  include  all  the  mea¬ 
sures  that  are  relevant.  Value  analysis  also  is  a  much  less 
rigorous  method  than  either  the  cost/benefit  or  system  anal¬ 
ysis  techniques.  Although  not  reported  in  the  DSS  litera¬ 
ture,  value  analysis  seems  very  close  to  the  intuitive  ap¬ 
proach  that  many  managers  use  to  evaluate  DSS  (18:166). 
Figure  J.3  summarizes  the  different  methods. 

Combining  Methods .  The  choice  of  evaluation  method 
will  depend  on  the  DSS  and  the  impacts  being  investigated, 
and  on  the  evaluator  and  the  environment  in  which  the  evalu¬ 
ation  is  performed.  Because  of  the  variety  and  complexity 
of  the  potential  effects  and  because  there  are  problems  with 
all  evaluation  methods,  a  combination  of  methods  will  proba¬ 
bly  result  in  the  best  evaluation.  The  usefulness  of  the 
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Comparison  of  Five  Methods  for  DSS  Evaluation 


event  log  in  explaining  changes  in  attitudes  has  already 
been  mentioned.  An  attitude  survey  measures  difference 
impacts.  System  measurement  analysis  uses  data  collection 
techniques  and  therefore  can  be  combined  easily.  Regardless 
of  which  combination  of  methods  is  chosen,  the  breadth  that 
the  combination  provides  to  the  evaluation  is  worth  the 
ef  fort . 

An  Example .  As  an  example  of  the  use  of  the  model  for 
DSS  evaluations,  consider  the  design  of  a  statistical  evalu¬ 
ation  of  the  impact  of  a  DSS  on  the  preparation  of  a  flight 
schedule  (summarized  in  Figure  J.4).  The  objective  is  to 
test  the  hypothesis  that  the  DSS  does  not  affect  schedule 
preparation  time.  The  measure  is  the  time  (person-hours)  to 
prepare  the  plan,  the  t-reatments  are  the  planning  procedures 
before  and  after  implementation  of  the  DSS,  and  the  experi¬ 
mental  units  are  the  schedulers  that  must  prepare  flight 
schedules.  Suppose  that  it  is  decided  to  use  the  system 
measurement  method  and  to  measure  preparation  times  under 
each  treatment.  A  random  sample  of  10  out  of  30  flight 
plans  is  selected.  The  analysis  criterion  is  a  comparison 
of  mean  plan  preparation  times,  with  a  significance  level  of 
0.05  (95  percent  confidence  of  accepting  the  evaluation  hy¬ 
pothesis  if  it  is  true).  The  plan  for  assigning  treatments 
to  experimental  units  is  to  block  on  schedulers  (i.e.,  to 
measure  preparation  times  by  the  same  scheduler  before  and 


METHOD:  System  measurement 


OBJECTIVE:  Test  the  hypothesis  that  the  DSS 

does  not  affect  scheduling  time 

MEASURE:  Schedule  preparation  time 

TREATMENTS:  Schedule  preparation  time  before 
and  after  the  DSS  is  implemented 

EXPERIMENTAL  UNITS:  Schedulers  in  the  organization 

PLAN  FOR  ASSIGNING  Measure  all  units  for  each 
TREATMENT  TO  UNITS:  treatment 

SAMPLE  SELECTION  PLAN:  Random  sample  of  10 

ANALYSIS  CRITERIA  AND  95  percent  chance  of  accepting 
TECHNIQUES:  hypothesis  if  true  using  paired 

test  (or  Wilcoxon  signed  test) 

DATA  (HYPOTHETICAL) 

SCHEDULER  BEFORE  AFTER 

(PERSON- HOURS)  (PERSON- HOURS) 


1 

11 

9 

2 

12.5 

8 

3 

11 

8.5 

4 

12 

8 

5 

10.5 

9 

6 

1 1 

7.5 

l 

12.5 

8.5 

8 

12 

9 

9 

11.5 

6 

10 

12 

8 

ANALYSIS  RESULTS 

PAIRED  t  TEST:  (t*  -9  )  Reject  hypothesis  (at 

0.05  level) 

WILCOXON  TEST:  (T*  0  )  Reject  hypothesis  (at 

0.05  level) 

CONCLUSION  There  is  sufficient  proof  that 

the  DSS  had  significant  impact 
on  preparation  for  the  flight 
schedule . 


Figure  J.4  Syllabus  Student  Training  Flow 
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Assuming  that  the  plan  preparation  times  are  normally  dis¬ 
tributed,  with  the  same  variance  for  each  treatment,  the 
analysis  technique  would  be  a  paired  test  (with  nine  degrees 
of  freedom)  of  the  difference  in  times  (see  Cody:91-94  for  a 
discussion  of  this  test).  If  the  assumptions  cannot  be 
made,  the  Wilcoxon  signed  ranks  test  could  be  used  for  the 
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Glossary 


Air  Combat  Maneuvers  (ACM) 

Air  Combat  Maneuvers  are  three  ship  aircraft  syllabus  sor¬ 
ties  that  practice  two-ship  offensive  and  defensive  moves 
against  a  single  defender.  Only  those  students  that  are  go¬ 
ing  on  to  the  F-15  aircraft  receive  these  rides.  The  two- 
ship  fighting  unit  is  stressed  as  the  target  jet  is  attacked 
and  defended  against. 

Aircraft  Configuration 
The  aircraft  configuration  refers  to  the  ordnance  that  main¬ 
tenance  puts  on  the  aircraft.  The  aircraft  configuration 
may  be  six  bombs  on  one  sortie  and  clean  (no  bombs)  on  the 
next.  The  configuration  must  match  the  type  of  mission  that 
the  aircraft  is  to  fly. 

A2£JLL 

The  American  Standard  Code  for  Information  Interchange 
(ASCII)  is  a  seven-bit  information  code  used  by  many 
computers  to  represent  letters,  numbers,  and  special 
characters.  Computer  microprocessors  interpret  this  code 
and  perform  commands  based  on  the  coded  instructions.  All 
user  inputs  to  ASCII-based  computers  are  translated  into  the 
seven-bit  code,  processed,  and  displayed  as  alphanumeric 


characters  on  an  output  device  (e.g.,  computer  screen  or 
printer) . 

Basic  Fighter  Maneuvers  (BFM) 

Basic  Fighter  Maneuvers  are  two-ship  aircraft  sorties  that 
practice  basic  offensive  and  defensive  maneuvers  against  an¬ 
other  airborne  target.  Early  rides  limit  the  maneuverabil¬ 
ity  of  the  opponent  to  allow  the  student  to  practice  against 
a  predictable  target.  Later  rides  have  an  instructor  fly 
against  the  student  in  predefined  scenarios. 

Check  Ride 

An  aircraft  sortie  used  to  check  the  instructor’s  perfor¬ 
mance  level  and  proficiency.  Two  types  of  check  rides  are 
given.  The  instrument  check  eva'  ’ates  the  Instructor  Pilots 
instrument  flying  ability.  The  qualification  check  tests 
tests  the  IP ’ s. instructional  talents. 

Crew  Rest 

The  time  span  from  an  aircrew’s  last  official  duty  to  the 
time  of  his  first  scheduled  event  the  next  day.  This  time 
must  not  be  less  than  twelve  hours.  Normally,  it  is  the 
time  an  aircrew  leaves  the  squadron  until  he  shows  up  the 
next  day. 
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A  Decision  Support  System  is  a  system  that  assists  in  making 
decisions.  A  DSS  is  usually  computer-based  with  access  to  a 
data  base  that  will  contain  information  required  by  a  user. 


Duly  Not  Involving  Flying  (DNIF) 

Duty  Not  Involving  Flying  is  a  category  of  pilots  that  does 
not  allow  the  pilot  to  fly  aboard  aircraft.  DNIF  occurs 
mainly  due  to  medical  reasons.  Any  pilot  that  cannot  par¬ 
ticipate  in  active  flying  must  be  classified  as  DNIF.  In 
essence,  DNIF  includes  all  those  pilots  that  are  not  physi¬ 
cally  ready  to  perform  flying  duties. 

Duty  QXiiger  (Duty  Bag) 

The  Duty  Officer  sits  at  the  front  desk  of  the  squadron  to 
ensure  that  the  flying  operations  run  smoothly.  The  Duty 
Hog  posts  takeoff  times  and  coordinates  with  maintenance  to 
get  tail  numbers  of  scheduled  operational  aircraft.  In  the 
case  of  a  ground  aborted  aircraft,  the  Duty  Hog  gets  a  dif¬ 
ferent  aircraft  for  the  crew  and  coordinates  new  area  (i.e., 
range  or  low-level)  time. 

Duty  Schedul er 

The  Duty  Scheduler  is  an  IP  that  generates  the  next  day’s 
schedule.  He  coordinates  with  maintenance,  operations,  and 
students  to  deconflict  the  next  day’s  schedule.  The  duty 


scheduler  is  responsible  for  completing  the  schedule  with 


any  last-minute  changes.  He  must  follow  any  and  all  syl¬ 
labus  rules  for  scheduling  student  rides.  He  must  ensure 
that  the  student  is  assigned  the  proper  event  and  has  met 
all  of  the  applicable  prerequisites. 

Event 

An  event  is  an  occurrence  that  is  scheduled  by  the  training 
syllabus  at  Holloman.  An  event  could  be  a  jet  training 
flight,  an  academic  lecture,  or  a  briefing.  Events  are 
scheduled  at  specific  times  with  specific  requirements  and 
prerequisites. 

Flight.  L&ad. 

The  flight  lead  is  the  designated  commander  of  the  group  of 
planes  in  his  formation.  The  flight  lead  briefs  the  mission 
1.5  hours  prior  to  takeoff.  In  the  briefing,  the  flight 
lead  covers  ground  operations,  takeoff,  departure,  mission 
elements  to  accomplish,  patterns  and  landings.  During  the 
sortie  the  flight  lead  is  responsible  for  the  actions  of  all 
flight  members. 

Floppy  Disk 

A  floppy  disk  (disk,  for  short)  is  a  thin,  encased  magnetic 
disk  upon  which  computers  store  and  retrieve  bits  of  infor¬ 
mation.  Much  like  a  cassette  tape,  disks  are  highly 
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portable  and  easy  to  use.  Microcomputers  normally  use  5)6 
inch  floppys  able  to  store  360,000  bytes  of  information. 

Formation  (Ea,rm) 

Formation  rides  are  aircraft  syllabus  that  increase  profi¬ 
ciency  in  basic  multiple-aircraft  formation  skills  and  sin¬ 
gle-ship  advanced  handling.  On  later  rides,  the  student 
practices  basic  four-ship  formation  and  two-ship  tactical 
f  ormation . 

Qreaaeboard 

A  greaseboard  is  a  smooth,  transparent  surface  upon  which 
users  write  with  wax  or  crayon-type  markers.  This  board 
usually  overlays  some  sort  of  spreadsheet,  and  is  easily 
erased.  This  latter  feature  is  important  because  users 
normally  use  greaseboards  to  record  information  which 
rapidly  changes. 

Hard  Driva 

Also  known  as  a  hard  disk,  a  hard  drive  is  a  magnetic  disk 
capable  of  storing  and  retrieving  tens  of  millions  of  bytes 
of  information.  This  capability  greatly  enhances  a 
computer's  ability  to  store  and  run  various  programs.  Most 
hard  drives  are  inside  the  computer  as  actual  ’hard'ware, 


hence  the  name. 


Instructor  Pilot  (12) 

An  Instructor  Pilot  is  a  pilot  that  is  qualified  to  teach 
students  how  to  fly  air  combat  and  surface  attack  (see  Glos¬ 
sary)  All  IPs  must  have  at  least  400  hours  in  a  fighter 
aircraft.  The  IPs  must  go  through  150  days  of  training  with 
other  IPs  in  an  upgrade  course  before  being  allowed  to  fly 
with  students.  On  training  missions  IPs  instruct  students 
from  the  back  seat  of  the  AT-38B  aircraft.  IPs  brief  and 
lead,  and  then  after  the  flight,  critiques  the  student's 
performance . 

Kernel 

A  kernel  is  the  central  or  essential  part  of  a  concept. 
Applied  to  a  DSS  (see  below) ,  kernels  are  the  central  parts 
or  ideas  which  make  up  the  entire  system.  For  example,  take 
the  act  of  withdrawing  money  from  a  bank.  The  kernels  may 
include  choosing  which  bank  branch  to  go  to  or  drawing  the 
money  from  which  account  (e.g.,  checking  or  savings). 

Another  kernel  may  be  deciding  where  to  draw  the  money  from 
(e.g.,  teller,  drive- through  window,  or  money  machine)  or 
how  much  money  to  withdraw.  All  of  these  concepts  are 
central  to  the  act  of  withdrawing  money  from  a  bank. 

Kay  Kernel 

The  key  kernel  is  the  fundamental,  or  most  important,  kernel 
about  which  the  other  kernels  center.  The  prospective 
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system  user  usually  selects  this  kernel  because  he  knows 
what  is  important  to  him.  Using  the  above  bank  example:  If 
a  person  wants  only  to  use  his  savings  account,  then  this 
may  be  the  key  kernel.  For  instance,  he  may  have  only  one 
savings  account  at  a  certain  branch  which  has  no  drive- 
through  window  or  money  machine. 

Kay  Keens!  System 

The  key  kernel  system  is  the  DSS  (see  below)  built  about  the 
key  kernel.  Consider  the  bank  example  mentioned  above.  The 
key  kernel  system  would  assist  the  user  by  providing  the 
information  necessary  about  his  accounts.  Thi3  DSS  would  be 
expand  at  a  later  time  to  include  the  rest  of  the  kernels. 

Load  In  Fighter  Training  (LIFT) 

Lead  In  Fighter  Training  is  training  given  to  students  who 
are  going  to  fly  fighter  aircraft  in  the  United  States  Air 
Force.  When  the  student  graduates  from  Undergraduate  Pilot 
Training  (UPT)  and  gets  assigned  to  fighter  aircraft,  he 
comes  to  Holloman  for  upgrade  training.  LIFT  teaches  the 
student  how  to  correctly  drop  bombs  and  fly  air  combat  cor¬ 
rectly  in  a  plane  he  already  knows  how  to  fly.  The  AT-38B 
used  at  Holloman  is  a  slightly  modified  version  of  the  T-38 
jet  trainer. 
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Letter  &i.  X  ’  3 

The  letter  of  X's  is  a  document  that  contains  all  of  the 
qualifications  of  all  a  squadron’s  IPs.  All  of  the  IPs 
names  are  contained  in  the  letter.  Beside  each  name  is  the 
qualifications  of  that  specific  IP.  For  instance  an  IP  may 
be  an  RCO ,  SOF,  and  a  red  dot  qualified  IP. 

Line 

A  line  of  scheduling  is  a  part  of  the  schedule  that  consists 
of  one  plane,  one  takeoff  time,  and  often  one  IPs  name  and 
one  students  name.  The  most  often  context  is  taken  as  a 
group  of  lines.  For  example,  the  schedule  consists  of  39 
lines  of  flying,  meaning  there  are  39  aircraft  sorties  with 
a  certain  aircraft  configuration  to  be  -filled. 

Macros 

A  macro  is  a  small  computer  program  containing  code  which 
tells  the  computer  how  to  perform  various  tasks.  Macros 
normally  contain  specialized  code  peculiar  to  a  computer  or 
a  larger  computer  program  (software).  The  computer  users 
usually  write  these  special  programs. 

Mouse 

A  mouse  is  a  hand-activated  peripheral  computer  device  which 
moves  the  computer  screen  cursor  in  response  to  it’s  own 
movement.  The  mouse  contains  one  or  more  keys  used  to 


initiate  various  computer  commands  and  functions.  It  is 


most  useful  in  spreadsheet,  word  processing,  and  graphics 
applications . 

Ma.vlg.ak.t.LQJX  (Nav) 

Navigation  rides  are  aircraft  syllabus  sorties  that  practice 
visual  low-level  procedures.  The  student  flies  the  aircraft 
at  500  to  1000  feet  above  the  ground  on  a  predetermined 
course  over  the  ground.  Later  rides  practice  low  altitude 
formation  maneuvering  in  a  two-ship  sortie. 

Range  Control  Officer  (RCO) 

Range  Control  Officer  is  a  qualified  IP  who  is  responsible 
for  the  safe  operation  of  a  controlled  bombing  range.  In 
addition  to- moni tor ing  range  procedures,  the  RCO  ensures 
that  the  weather  conditions  are  appropriate  for  dropping 
bombs  safely.  Every  airplane  must  have  radio  contact  with 
the  RCO  to  drop  bombs  on  that  bombing  range.  The  RCO  also 
supervises  several  personnel  for  range  maintenance. 

Red  Dot 

Red  Dot  is  a  status  that  refers  to  students  and  instructor 
pilots.  A  red  dot  student  is  a  student  that  needs  extra  at¬ 
tention  due  to  unusual  circumstances  or  proficiency.  Per¬ 
haps  the  student  has  had  a  long  layoff  from  his  last  flight. 
The  operations  officer  of  each  squadron  screens  the  incoming 


students  for  any  unusual  circumstances  and  assigns  that  par¬ 
ticular  student  a  'red  dot’  status.  The  only  instructor  pi¬ 
lots  to  fly  with  a  red  dot  student  are  red  dot  instructor 
pilots.  Only  the  more  experienced  instructor  pilots  acquire 
red  dot  status.  The  idea  is  to  match  up  experienced  in¬ 
structor  pilots  with  less  proficient  students  for  safety  and 
instructional  reasons. 

Scheduling  Shell 

The  Shell  is  a  list  of  takeoff  times,  area  times,  number  of 
aircraft,  and  configurations  that  constitute  the  starting 
point  of  the  daily  schedule.  The  Wing  Scheduling  shop 
deconflicts  takeoff  and  area  times  among  the  four  squadrons 
at  Holloman  and  publishes  the  shell  weekly.  The  schedulers 
at  each  of  the  four  squadrons  use  the  shell  as  an  initial 
input  to  the  daily  scheduling  process 

Storyboard 

A  storyboard  is  a  phrase  coined  by  cartoonists  to  denote  a 
single  picture  in  a  series  of  animated  pictures.  This 
single  picture  was  an  important  to  the  animation  in  that  it 
reflected  a  main  concept  about  the  story.  Consider,  for 
example,  a  cartoon  showing  Mickey  Mouse  at  an  amusement 
park.  The  first  storyboard  may  show  him  at  the  gate  counter 
buying  a  ticket.  The  following  ones  may  show  him  riding  the 
ferris  wheel,  merry-go-round,  and  side  show  in  succession. 
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In  this  way,  the  storyboard  shows  each  important  step  in  the 
animation.  Applied  to  a  DSS  (see  below) ,  the  storyboard 
shows  each  important  computer  screen  necessary  to  complete 
the  entire  system. 

Supervisor  of  Flying  (SOF) 

The  SOF  is  a  qualified  IP  who  is  responsible  for  the  flying 
operations  of  all  the  AT-38s  at  Holloman  AFB .  He  has  the 
authority  to  cancel  flights  due  to  weather  or  other  circum¬ 
stances.  He  also  is  there  to  assist  any  aircraft  should  it 
experience  an  airborne  emergency.  The  SOF  also  resolves  any 
conflicts  that  are  happening  during  flying  operations. 

Surface  Attack  (£A) 

Surface  Attack  rides  are  four-ship  aircraft  syllabus  sorties 
to  practice  basic  range,  bombing,  and  strafing  procedures. 
The  student  drops  practice  bombs  on  a  controlled  range 
during  this  phase  of  training. 

Timeline 

The  timeline  is  a  measure  of  each  individual’s  or  class’s 
currency  according  to  the  syllabus.  Each  event  is  listed  in 
the  syllabus  on  the  day  it  should  occur.  If  all  events  oc¬ 
cur  when  they  should  then  the  timeline  stays  at  zero.  How¬ 
ever,  if  the  student  or  class  falls  behind  for  some  reason 
then  the  timeline  will  reflect  the  difference  between  the 
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number  that  should  have  occurred  and  the  number  that  have 
already  occurred.  For  Instance,  if  the  student  or  class  has 
accomplished  34  events  by  the  23rd  day  and  the  syllabus  re¬ 
quired  37  events  by  that  time,  the  timeline  reflects  a  -3. 
The  -3  indicates  the  student  or  class  is  3  events  behind  the 
syllabus  schedule. 

Transition  (I£) 

Transition  rides  are  single  aircraft  syllabus  that  get  the 
student  familiar  with  the  aircraft  again.  The  student 
learns  handling/aerodynamic  characteristics  of  the  AT-38B 
and  is  introduced  to  the  local  flying  area.  The  student 
also  practices  takeoffs  and  landings  at  Holloman  AFB . 
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